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.
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.
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.
Just some custom assets I’ve assembled/created and implemented into my code. They should be replaced with proper artist assets later on but its more of a demonstration of a custom weapon that reloads, animates, plays sound, etc without any ut classes.
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.
