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.
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.
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!
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.
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):
Stay tuned, more posts will be coming today!
Hey guys I haven’t posted in a while – but I’m going to make it up to you guys by giving you a tutorial. Game-Maker: Studio is a really neat piece of software and the guys over at YoYo Games are really doing a good job with the community and customer support. I bought the Professional Version of Game Maker Studio about 4 or 5 months ago and even though I don’t use it much(because I prefer coding in a regular IDE), it is a great way to learn the ropes of Game Development and Game Logic in general. A lot of people believe that Game-Maker is not a legitimate tool in Game Development however I disagree… this is simply not the case. Not only does Game-Maker have drag and drop features(for beginners) it also has it’s own scripting language called GML which allows you to accomplish more advanced tasks that drag and drop features wouldn’t do. Not only that – a lot of great games have been made with the software. Super Crate Box by Vlambeer is probably the best example I can give you. Vlambeer happens to be on my top 3 list of Independent Game Development Studios and they make almost all of their games in Game-Maker and they continue to release successful and popular games.As long as the game is fun and engaging it really doesn’t matter what you use to make it. Make sure it fits your games needs, not other peoples opinions on what you can and should not use.
Alright, fire up GameMaker-Studio and create a new project called “Invaders Remake” or something to your liking. Make sure you store it in folder where you can find it again. On my computer, I have a folder filled with all my Game Maker Studio Projects and within each of these folders are the scripts, the extensions, and the assets. Make sure you update the software if you haven’t already.
Assuming you have familiarized yourself with the Game-Maker GUI and you know what sprites,sounds,fonts,objects,scripts, and rooms are in Game-Maker then keep reading. If not, try taking the tutorials that come with the software – or try reading another basic tutorial that attempts to explain the function of some components that make up a game in game-maker. If you know what I’m talking about then this tutorial is for you. Let’s get started.
Create a new room, name it something like “mainRoom”. Try to make everything you have in your game-project have a significant name. Make sure that mainRoom has the width of 640 and the height of 480. Speed should be set at 30. The room should not be persistent so make sure that it is unchecked. Navigate to the backgrounds tab, and make sure that “Draw background color” is checked. Make sure that you make the background black. Background 0 should be selected from the List View while you are performing these operations. When you are done hit the check mark in the top left corner. This finalizes the changes you have made and cannot be undone.
It’s time to make the first object to our game. We are not going to start with the enemies right away but instead get the player working first. Go ahead and take this sprite:
and plug it into your project. Since it is a sprite you may prefer to name it with an “spr_” prefix before the objects name. I decided to call it “spr_shooter”. This sprite will not be animated. Click the center button in order to get the sprites origin then click OK. Now that we have the sprite we need to create the corresponding object so that we can control the player. Once again you may wish to name the object with a prefix like “obj_”. I decided to name my object “obj_shooter”.
Make sure you have the obj_shooter’s properties window open. Set the sprite to spr_shooter. Make sure that the Visible checkbox has been checked. We do not want the object to be invisible when we put it mainRoom. Make sure depth is set to 0. There is no reason to check the boxes for Solid, Persistent or Uses Physics. There should be no parent to the object and the Mask should be set to “<same as sprite>”. It is now time to add some functionality to the object – or in other words, add some events!
Go ahead and add a create event. This event gets triggered whenever the object is spawned into a room. In other words it is it’s initialization event. Make sure that you have the Create Event selected. Now it is time to add some actions to this event. Go ahead and add these actions:
As you can see in the image above I set the objects health to one, then defined a variable called to_shoot to one. to_shoot is sort of like a boolean variable but instead of using true and false values I decided to use numbers. Personal preference. However the 1 is true and the 0 is false. We will be making the player shoot bullets in another tutorial. Add another event – this time a keyboard event which checks to see if the user has pressed the Left Arrow on the keyboard. Add these actions to that event:
We can make the player move left just like in the original arcade game however we cannot move him to the right. Let’s make this possible by adding another Keyboard Event but this time for the Right Arrow Key. Here are the actions you need to add:
Click the okay button then navigate back to mainRoom and add the object preferably as close to the bottom of the screen as you can. If you are satisfied with the controls you may want to see if you can add your own spin on it. Maybe you can have it move up and down? Who knows. Part 2 will be coming soon. Please let me know if you have in problems with this tutorial or have any questions. I’ll answer them as soon as possible.
14 and counting.