A Year In , a Year Out – 2013

Standard

Tomorrow marks the start of a new year. I am quite satisfied with my achievements in 2013, and am looking forward to the new set of opportunities the new year will bring

.My programming skill has increased exponentially and I am beginning to take steps towards learning how the web works. One of my accomplishments this year, was being able to create a website from scratch using barebones HTML 5, CSS3, and PHP. It was a great learning experience and I will definitely be pursuing web development years to come.

I spent a year with Unity. It’s a great tool – and I’d recommend every hobbyist(and even serious) game developer out there to give it a shot, whether you’re doing 2D or 3D game development. It’s a capable tool, and even though some aspects of Unity may have a high learning curve , the reward outweighs the time spent learning it. After having used Unity for a year, it has definitely affected the way I work outside of it – mainly because of the comfort and protection it offers against lower-level programming(programming with a framework with no GUI based tools for example). This is unacceptable so this year, 2014, I will make sure that I cut down on my usage with Unity when it comes to making games.

I’m a desktop developer at heart, and I’ve never really done serious web development or even mobile development. This year, I plan on doing both mobile and web development. I’ve had a few ideas that I think could really do well when given to a mobile audience but I haven’t had the skills or the know how to do so.

That about sums things up. I hope you’ve had a productive year as well, and are looking forward to seeing what the new year brings. Stay sharp, and keep making things.

The Curse of the Sandboxed Developer

Standard

So me and a friend, gamepopper attempted to make a game for Ludum Dare 28. It was really fun and I learned a lot about myself and about AS3 and Flixel.

AS3 is both a statically typed and dynamically typed language that support both weak typing and strong typing. Flixel is a framework that allows flash developers to make games easily and quickly. What made this game jam good was that I got to use something other than Unity to make a game. Sure it wasn’t actually a game but I still did something in it along with the help of my team mate.

The bad? Well I wasn’t familiar with AS3 or Flixel so I spent lots of hours fixing simple syntax errors and wrapping my head around how certain features worked in flixel. It came to my attention immediately that I struggled with making everything from scratch except websites. This is disturbing. I’m a “developer” who can only create meaningful creations in a GUI Based Tool called Unity. There’s nothing wrong with using the tool except becoming too comfortable with it. I’ve been using Unity for close to a year now, and I’ve become too comfortable with it to the point where it’s effecting how I operate without it. I have always struggled with making things from scratch and using GUI Based tools are not going to help with that. They are preventing my knowledge from growing and preventing me from getting exposure to the technical details of X or Y product I’m developing. While it may work for you it does not for me. It never will. It’s good to use for somethings but all the time? No. It is time to take the training wheels off.

20131216-195716.jpg

TRTWNT and other things.

Standard

TRTWNT’s development has fallen off. No it’s not dead, I just took a breather from it while I healed my shoulder( long story short, I sprained it and it had really bad inflammation). During that period I worked on some other things but it’s near time to start working on it again. I am pleased to announce that a new team member, Ultifinitus, will be joining the dev team. He’s a seasoned developer and I’ve known him for quite a while now. The fact that he mentored me when I was just a wee grasshopper in programming makes the dev team a bit special.  You can expect to see more posts about TRTWNT here in the near future.

So what did I do in my down time? Well, I made a website for an LP’er , and I am working on a short atmospheric platformer in Unity. While I may not finish it it was something else to work on and keep myself sane. I would post screenshots here – but you can actually play the build in the “In Development” sections of my website. Make sure you’ve installed Unity Webplayer and you are good to go.

Game Engines v.s Actual Games

Standard

WARNING: Highly opinionated post – so if you don’t want to get your pride or your feelings hurt turn back now.

Before I get crucified, I’d like to state that both have merit. I am not saying that game engines are better than making games and I am not trying to say that games are better than making engines. Both have their merits and can be developed in different scenarios. Game Engines facilitate how a game is made. It’s the back-end tech behind the game. A game, when using an engine, is the product of using X or Y existing engine.

Now that you know the context in which I use these definitions, I can give my argument.

It’s all about the cost.

Duh. There are two mutually peaceful and loving  groups of game developers in our industry. Independent Game Developers(usually one to two man teams) and AAA Game Developers(no need for an explanation here. They are usually found in groups  I might add). Let me give you a scenario:

Bob is an indie game developer. He’s a one man show. He has a wife, kids, and a family. He doesn’t have a day job and he’s going all-out (meaning that his games are the only thing that supports his family’s well-being). Bob likes to write clean code and takes pride in everything he does. He is especially fond of making things from scratch. One day, Bob has a new game idea. Instead of making the game right away by using existing engines he begins to roll everything from scratch. He toils day and night, over his keyboard for 6 or 7 months. He smiles at his handy-work. His engine is over 15,000 LOC, loosely-coupled, and demonstrates the most modern practices. Finally, Bob begins to make the game. He takes another 2-3 months to make the game and finally shows the world what he’s been making. He releases it on all major distribution platforms but the game still has low popularity and it only brings in < 2,000. Bob is distraught and his family suffers from his negligence and pride. 

Why did Bob lose? It’s because he wasted time building something that his consumers wouldn’t care about – and forgot what they are really there for. Which is the finished product, or in case you didn’t catch it – the game. Most of the people that play your game aren’t going to buy your game because of the tech it was built on. They don’t care if you built it using Irrlicht and C++ using the most modern techniques. They don’t care if you built it in Unity in two days. The only thing they care about is the quality of the game. If that’s a pass, then your game will most likely successful. If not, it’s back to the drawing boards. Game Engines are only going to give you a “pat on the back” at the end of the day and perhaps speed up the development but it does not ensure, a game of quality. Plain and Simple. So please, developers, don’t let your pride get in the way of the big picture.

Here is yet another scenario – something of which I find respective of most AAA Game Studios(it wouldn’t be right to say developers, so I’ll refer to them as a whole in this case). I’m not going to call those studio’s out ( I’ll leave it to you to find out which ones fit the description).
For the examples sake I am going to refer to this studio as XYZ Studio.

XYZ studio is at the top of their game. Their quarterly earnings are stellar, and they’ve got investors coming at them from all angles. They have a successful franchise going, a loyal fan base, and they are on all major platforms. A new year is starting and they are getting ready to gear up for their next installment. Having spent majority of their time developing the tech for the series in the first game making the next game will be fairly simple. They pride themselves in knowing that they have an engine behind their game, and rightfully so. Their engine had provided them with an easy way to easily create other installments in the franchise. They had a loyal-fanbase behind it as well so they could easily say that the cost didn’t outweigh the benefits. Christmas comes around and they release the game. It is an instant hit. They repeat the next year.

So why did the AAA Game Studio’s get away with using an Engine and the Indie Game Developer didn’t? Even though both have little margin for error when it comes to releasing successful games, the AAA Game Studio had a fan base behind the game. They had access to a wide range of players which are consoles of course. In a way one could say that their success was guaranteed. They had a tried and true formula for success and they were going to milk it.   They also had more man-power behind the development of the engine so they don’t need to spend a significant amount of time developing it – while the indie game developer has to do both for the game engine and the game itself. I’d go so far as to add that most releases in a series are really just the same game with one or two new features. They only spend time developing new art, story, and audio – and the game sells. The general public of gamers won’t realize this because all they care about in the end is something significantly different from the past game AND its quality.

To sum up my argument, as an indie game developer your focus should be solely on making the game – and don’t become focused on the tech behind it unless you are dead sure that the time you invest in the engine will pay off. If the cost outweighs the benefit then you are going to lose, rather than win. As an AAA game studio you can spend time “playing around with tech” rather than focusing on the game because of your manpower and time benefits that an indie usually doesn’t have.

 

Remaking Space Invaders in Game Maker: Studio PART 2

Standard

This is a continuation of the Space Invaders Game Maker: Studio tutorial. Make sure that you have completed the steps in Part 1  . If you have – good for you. Let’s begin.

Just to refresh your memory, Part 1 of the tutorial ended with us setting up player movement. Well we are no where near finished with the player. An integral part of Space Invaders is allowing the player to shoot, in order to defend the bottom of the screen so in this part will be adding this functionality. For those of you that have actually played Space Invaders you know that it is perhaps one of the most notable arcade games with the One Bullet At A Time rule.

The shooting in Space Invaders basically works like this: You cannot shoot/produce another bullet until you hit an enemy or until your bullet goes off screen. This makes the game very challenging, so feel free to improvise where needed.

First of all, we need a sprite for your bullet. It can be a circle, a Ziz-Zag a triangle, whatever you want it to be. For the sake of being “historically accurate” I’m going to use an elongated rectangle just like classic Space Invaders game used. The color should also be the same as the cannon sprite that we used in the previous tutorial. It’s RGB value should be (0,255,0).  You can also use white. Whatever color you choose, our background will always be black. Here’s the sprite that I am going to use.

(6×16 Solid Green Rectangle. Otherwise Known As Our Bullet)

This sprite will not be animated. Once you’ve made your sprite, it’s time to make the bullet’s object.  Create a bullet object and give it the corresponding sprite, which should be the sprite that you are using for the bullet. Once you’ve done that it’s time to populate the object with events/actions. We will be editing this object in another part but for now, add a Create event to your object. In this event we need to give our object  some speed.  If you’re a keen observer, you should have noticed that our ship will be shooting vertically rather than horizontally. This means that we must alter the objects vertical speed. This variable is shared among all objects and it is called vspeed.

The create event will only be populated with one Action – and the action we are looking for is under the Control Tab. It allows you to set variables to any desired value. We will set vspeed to -8 for now, although you can tweak this value to your hearts desire later on.  This is all you should have in the actions portion of your Create event:

We are almost done with adding content to the bullet object, but now we need a way to delete bullets as we don’t want to create unnecessary performance issues with our game due to us not deleting objects properly. We simply need to check if the bullet goes out of bounds( for now, because we don’t have any enemies in our room yet).

Add an event to your bullet object(under other) and you should see a context menu popup. Select “Outside room”. Once this is done, we need to populate the event object with actions. The only action we need for this event is under the main1 tab. It looks like a trash-bin with a recycle icon on it, but this basically destroys the instance once it exits the rooms boundaries.  After you have done this, it is time to actually allow the player to shoot these bullet objects that we have created. Before we do this make sure that the Visible check-box is checked under the bullet object properties. Nothing else should be checked. We don’t want the player shooting invisible bullets do we? Although you can certainly do that if you wish, haha.

We are done with the bullet object now so you can close that and save the project. Save often as you don’t want to have to rewrite things over if Game Maker unexpectedly crashes on you. Open up the shooter object, and look in the Create Event. So far there is only one action here, which gives the player one health. This is kind of useless to us now, because we don’t actually have any enemies but we will in later parts of the tutorial – but keep it anyway!

Go ahead and get the “Set variable…” event and drag it into the actions box.  The variable that we are creating is a boolean variable and it will determine whether or not the player can shoot. We must set this to true when the player is created, because it can be safely assumed that the player has not actually shot anything when he is spawned into the room. You can name it anything you want, but just make sure it has meaning. I named mine to_shoot, although I think can_shoot would be better in this case. Remember that 1 is true and 0 is false.   Here’s a screenshot in case your lost:

Now we need to make sure that this variable actually updates itself. Remember that if the bullet exists and is inside the screen, this means that the user has already shot, and we need to make sure that it is false. However if it doesn’t exist that means that the user hasn’t shot, and we can set the variable to_shoot to true anyways. So let’s do that. Create a Step Event.  We need to test if an expression is true, and you can find this action(as a ? mark) in the Control tab Under Questions. Double click the action and make sure you have this stuff in it:

Make sure that NOT is checked. Let me explain what we are doing here. We are testing to see if the instance does NOT exist (hence the checking of note). So we are looking for this to return false, and if it does…. well, we set the variable to_shoot to true.  I’m not going to explain how to do this since it is fairly straight-forward.

Okay next – add a keyboard event that looks if the Space Key was pressed. Then add these actions to the event.

Basically you check to see if the player can shoot and if so we create an instance of the object. Then we set the variable of to shoot to false(until it goes out and deletes itself – in which it won’t exist anymore!). As for where to spawn the object, you’ll have to play around with it(based on what sprite you used), but for mine I used the position (1,-10) while keeping those coordinates relative to the object(so make sure the relative tick box is checked).

Your player should now be able to shoot! Once again, if you don’t like how fast the bullet is going just tweak the speed values. If you have any questions please just let me know in the comments or send me an email. If you’re actually following the tutorial just leave a friendly hello in the comments as well. Keep coding and keep making games!

Announcements

Standard

Hi guys,

You’re probably wondering what happened to that zombie shooter I am supposed to be prototyping right? Well, that guy wasn’t serious and I’m not going to work with people who aren’t serious about their work. That’s just wasting my time. Anyways I was doing the DevelTeam Game Jam (their first one), but I didn’t get it out in time due to IRL situations. However, I am going to try to release the game for a modest sum on the App Store. I’ll be posting more regularly about the project here.

I am also happy to announce that Project Minimal will be developed again – this August 22nd! It’s going to be great getting back into the groove with that game. Like I said – I have high expectations for it so let’s hope everything turns out well.

- CA

Involved in a new project

Standard

Jeeze – I’ve fell off of blogging haven’t I? Well no matter, I’m back on track and I’ve got some good news.

I’m still working on the backup software and it’s coming along nicely. I still have loads more to add to it, and will be making some blog posts about it later today. In the mean time, I’ve involved myself in a team project with someone on newgrounds who was in need of a programmer to program a prototype. He goes by the name of Robert and is affiliated with iWarpStudios. I hope it can become a nice partnership and hopefully a good game will come out of it. He’s going to send me some concept later today, if he manages to keep his word I will for sure do some Dev on our project today. Here’s some concept that he’s drawn up(characters at least):

 

A group of rough looking fellows who have seen some serious crap!

 

Stay tuned, more posts will be coming today!