Today I decided to switch gears back into actual tower development, as that is the real nature of the game isn’t it? In any case, we need a way for our enemies to be registered as enemies for our towers. We don’t want our towers to be attacking every actor that is within its range, it should only track and attack enemy targets. To do this, I’ve decided to make another Interface that way I can make any class an enemy instead of having all my enemies derive from a single class. Right now there is no actual use of the interface than to register a class as an enemy, but I’ve decided to throw in a function that could be used to allow for classes implementing this interface to decide that a particular instance of it is not an enemy. Today I haven’t created that checks this or requires this, but I think it might come handy in the future.
Yesterday I spent most of my day eating pizza and working on Warm Gun over at Emotional Robots, Inc., but I managed to put a little time in this morning to this side project.
Day 4 (11/21/2010)
9. Setting Up Basic Interaction Logic From Mouse To Towers
While our towers are just shell Pawns that aren’t doing much, before I give them more functionality I wanted to tackle how the player is going to interact with the unbuilt towers so that they can build their own. The first step is getting some sort of simple detection going on that would let the towers know if they were currently the target for the players mouse and then to figure out if the player was within an ‘interaction radius’ with the tower. Doing so, the player will only be able to interact with tower building zones when their Pawn is close enough to the tower, causing the player to have to run to wherever they want to place their towers for a bit of a fun challenge. If this proves to not be fun, I can just either increase the interact range greatly or remove it all together. Also, I wanted this detection logic to be able to be applied to any actor I choose instead of having every actor derive from an interaction actor. To do this, we have to use an interface. Interfaces are kind of like sub classes, but they list a series of functions and delegates (no local variables) that each class using it must implement. To implement an interface, you just use the keyword ‘implements’ in your class declaration. More information about interfaces can be found on the UDN page.
The interface is really simple for now, it has a function that returns what type of interaction it is, functions to show/stop showing the player that the object is interactable, and then finally an actual interact function.
Now that I got the camera set up yesterday and played a lot of Vindictus, its time to get back to work. The next step is to get the player to aim towards where their mouse instead of in the direction the player camera is facing. This way movement and aim will be separated and allow for interaction with the world with the freedom of rotation but locking movement to the camera axis. Basically, the player will be controlled like most top-down shooters. Now for this project I am currently using the September build of UDK even though the October build is out as this project is also meant to help some classmates with their project which is currently September based. The reason I bring this up is that the October build of UDK strips out all UIScene functionality completely and everything related to it and in the past the class UIRoot was my primary way of accessing mouse coordinates. This means that for my project to not need a major reworking in the future I would have to find a new way to grab mouse coordinates. Now I looked all over the UDK development code and I could not find a straightforward way to do so. If there is a easier way than the process that I went to that I will go over, please let me know. The way I did it relies on a SWF to store mouse coordinates which then UnrealScript grabs. Its a little odd but it works flawlessly once set up correctly. I figured that if I used ScaleForm to grab mouse coordinates, Epic won’t be scrapping ScaleForm any time soon.
The first thing we are going to need to do is to replace the UT HUD with our own ScaleForm based HUD. As fancy as the UT HUD is, I’d rather have my own. Also, I need to create mouse coordinate functionality without relying on the old hud’s Canvas to use DeProject, which I’ll get into later. For now, I don’t need anything fancy in my HUD except a mouse cursor which will indicate where the player is aiming and will also serve as a cursor for UI interaction with HUD menus and things. Time to start up Flash and build me a HUD. I am using a trial version of Flash CS5 at the moment.
With Flash CS5, I have already set up my ScaleForm extension and my ActionScript settings. If you have not dealt with ScaleForm and Flash before, I strongly encourage checking out my ScaleForm series here. With my new flash document open, I went ahead and drew myself a cursor with the flash tools, and this is what I came up with:
If you don’t know about my Tower Defense Side Project, please read Day 1 here.
Day 2 (11/20/2010)
5. Creating The Camera
I’ve done a few third person cameras before so I was able to implement this system within a half hour. I did research some examples of isometric cameras beforehand however, and I ended up starting with this tutorial here (at X9 Productions) by Christian Roy. His provided code was simple and elegant so it would serve as a perfect slate to base my camera logic on. After implementing his tutorial code however, I found that my ‘isometric’ camera was only being properly shown if I typed behindview in console, but this is because I implemented it as a child of UTGame and not GameInfo. Normally I don’t derive from UTGame but in the case of this project I did not want to have to deal with creating a new code base, but this also causes small issues like these. My solution was to simply force a SetBehindView call on the Pawn during its PostBeginPlay function and that remedied things for the most part. I also had to edit the CameraOffset and the CameraScaleMax variables to get the angle I wanted the camera to be at. Roy’s tutorial implementation does not support camera zooming (however the source code he provides for download does, but I chose to implement it differently). I wanted it so the camera would stay locked and you can’t zoom or rotate it unless you held down the middle mouse button and then moved the mouse or scrolled. In order to accomplish this, the first thing I had to do was to edit DefaultInput.ini and add the following bindings:
This way two functions would be called, one when the MiddleMouseButton was pressed or released, and one when the scroll wheel was scrolled. AllowCameraMovement(bool bEnable) toggles whether or not the camera should rotate or zoom with the mouse, and HandleMouseScroll(bool bUp) handles what to do when the mouse is scrolled up or down. Read the rest of this entry »
So a class at my school, the Art Institute of Orange County, called Advanced Level Design has 11 weeks to create a Tower Defense game. I’ve already taken the class, but I have a few friends taking it now. They are currently seven weeks in and are only in the blockout stages of the game. I’ve been asked by a few of these students, and also by a significant amount of people through e-mail about how I would approach building a Tower Defense game in terms of design and implementation with UDK but I don’t have any experience in making a Tower Defense game at all. Well thats now going to change.
Taking a note from Dungeon Defense, I thought it’d be nice to document my approach and maybe give some info about how certain things can be implemented. In no way do I claim that this is the ‘right’ way of doing things. This is a purely experimental project to teach me things about AI, pathing, and etc that I haven’t had any experience with yet. In any case, here we go.
Yeaaaaaaaaah I don’t really have a design document. I’ll design elements as I go. This is a very very bad route I know, but I want to get right into testing out implementation features and building stuff.
2. Designing The First Level
Designing the first level for a new game is one of the biggest hurdles that a team can face. The first level is where everything ‘hits the fan’ for the first time, although definitely not the last time. It is where you realize that your design doc may be lacking in some areas, or simply void of needed information all together. The first level also demonstrates how well the team is coordinated and if the vision for the game was successfully synchronized amongst the team members. While the first level design should be one that is well thought out and discussed to no end, it is also the design which you must be the most accepting to throw away. Rarely does the first level come to fruition in the same way that the vision intends, either due to design flaws, technological barriers, or simply the team just doesn’t want to do it anymore. With these snakes and spikes riddling your path on the way to get your first level implemented, one should design the first level in the simplest way possible that will just touch on the designs of the game instead of trying to fully implement every single feature immediately upon game start. Not only will this let you build levels iteratively and incorporate more advanced design implementations later as the pipeline becomes more concrete, it gets people working on small manageable tasks that they can envision done by the end of the week instead by the end of the quarter.
Project Lead for The Hunt, a student based game project I am currently Technical Director/Lead Programmer of, recently did a bit for Time Warner Cable. I’m the guy with the long and rattly hair lurking in the occasional shot. No true official coverage of me, mainly because programming just makes some boring television.
I know I haven’t been able to upload some new UnrealScript tutorials in awhile, and that is because school has flooded me with work and I also have to catch up on a lot of work I need to do for a few team projects (The Hunt and Western Mercs). I also have been working on my book.
While I don’t know how much time a week I can devote to tutorial making, I will be trying to do a short video at least once a week talking about the progress I’ve made on the projects I’m working on in an effort to share my development pipeline experiences week by week and allow me to remember what I did that past week. It might actually be interesting, or really boring. In any case, I hope you tune in a bit some times.
These “Dev Diary” entries will generally be in video form. I am considering hosting these entries on YouTube or a similar video hosting site. We’ll see how that goes.
Well, here goes the first video. Looks like its already unsync’ed, and stuff, great. I’ll be uploading my videos from now on instead of doing direct webcam recordings.
This upcoming week is finals week at The Art Institute of Orange County, so tutorial making will be slowed but not it shall not stop.
I was hoping to have a lot more weapon implementation up by today, but thats okay. I have quite some content already done that just needs uploaded and formatted and I’ll get to it when I can, I just have to hammer out a few school projects first.
