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.
Sorry I’m 7 hours late with this posting, had to do some stuff.
Day 6 (11/23/2010)
11. Weapon Archetype System
When designing the system for towers to be placed, I thought it would be cool to only have a few base tower classes and then allow for a lot of per tower customization and attributes through the use of Archetypes so I can tweak settings within the editor instead of compiling every time I wanted to change a setting and so that if anyone picks up my project they can add their own towers by just creating archetypes instead of figuring out how to derive and code their own towers. I figure I want to make modding design elements as easy as possible so that if one design doesn’t work I can quickly switch to another. The problem with this was, I have had no experience in creating a dynamic system that uses object archetypes rather than actual hard coded classes. Being that towers might be a complex feat to make into an archetypal system as my first project with archetypes, I decided that I should convert the current weapon system to use archetypes so I have something to base on. This took a bit of time to figure out all the kinks, but what I ended up with was a solid base for a really cool way to create new games with ease and test weapon systems without compiling. This means that once I fully develop a custom weapon class, all in-game weapons will be based off of the same weapon class but their attributes will be set with object archetypes. Of course, the archetypal system should also allow for archetypes of classes that derive from my base weapon class, and that is supported simply by the fact that UnrealScript is already heavily object oriented.
Here is a really long and boring video of a brief overview of my most recent Dev Diary posts and how to use the Weapon Archetype System. One day I’ll get a better voice, I swear. <_<
So… today I was at school all day, only was home for 7 hours. I didn’t do much except layout some basic design for my HUD… this is what I came up with.
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.
Sorry about the long time between posts… been working over at Emotional Robots, Inc so I’ve been busy working on stuff I can’t talk about… but I have a pretty big update coming soon that I know a few people out there will really enjoy. in the mean time, heres this.
Parallax Occlusion basically makes shadowy parts where you expect shadowy parts on objects, but with parallax. The wall that you see is a piece of completely flat bsp.
Created a 3d model of my head with FaceGen
Adrian Rodriguez rigged it and did some fancy FaceFX graph stuff.
Nicolas Ziegler lent his voice.
I imported .wav files, edited their animation graphs, shoved it all in mattinee.
