It's all in the title, and the embedded video!
Showing posts with label Unreal. Show all posts
Showing posts with label Unreal. Show all posts
Thursday, February 23, 2012
Saturday, February 18, 2012
IDE Feature Set
I'm currently traveling down the road others have gone and trying to create an UnrealScript IDE myself as well. nFringe and WOTgreal and some of the newer attempts are all usable and nice, but none of them are as lightweight as I want and are either missing key features, aren't extendable to include features I want, or are outdated. Hopefully I should have a prototype by the end of the week, but if you have any suggestions for what you would like to see in an UnrealScript IDE please comment away your suggestions.
Wednesday, February 8, 2012
Kyle's Modular Building!
So if there was any way to build a level fast and efficient its some modular building. I suggest if there are any of you artists out there that love environmental building, look into this because you will instantly make a level designer your best friend. Here below are a few pieces I modeled & textured out, with this set I can make hallways all day, throw in some rooms and clutter... Waala! You have yourself a pretty decent level to go around go play, tweak, and then refine.
If you are going to try to start making some modular pieces here are some tips:
- ALWAYS stick to the grid, make sure everything will snap just right.
-Try to work within the a power of 2 (specifically 256 or 512 sizes) .
Everything has to be extremely precise, otherwise it will end up not fitting correctly when you import it into your favorite editor. But once done right, can be super powerful. One good read about modular pieces is this. I will update the hallway above, maybe even with some game-play!
Monday, February 6, 2012
Frustration: ScaleForm GFxMoviePlayer Not Calling Init
If your GFxMoviePlayer isn't calling your Init function, I bet you are loading your custom GFxMoviePlayer class through Kismet.
Apparently Kismet fires Start but not Init, at least that is the conclusion I just came to. I didn't find any documentation on this so I'm posting it here for reference.
Apparently Kismet fires Start but not Init, at least that is the conclusion I just came to. I didn't find any documentation on this so I'm posting it here for reference.
Friday, January 6, 2012
Beginning Your UDK Game: Tools Setup
Hello reader! Whether or not you are brand new to programming in general, programming with UDK, this will set you up with the tools you need to have to make awesome!
At the end of this tutorial, you will have:
Things you will need to download:
This video comes in two flavors. The first video is for people who are brand new or have no idea whats going on:
This second video is a much shorter rapid fire approach to the above, and is either for those without patience or who already know what they are doing but would just like to get Visual Assist X working properly:
At the end of this tutorial, you will have:
- A copy of the Unreal Development Kit installed (at the time of writing, version Dec. 2011)
- Visual Studio 2010 with Version 1862.1 or higher of Visual Assist X installed with UnrealScript auto-complete
- Or Wotgreal if you do not have access to Visual Studio 2010
- UnCodeX for browsing UnrealScript code
- Everything set up for you to begin a new game project!
Things you will need to download:
- The Unreal Development Kit
- Visual Studio 2010 (or Wotgreal)
- Version 1862.1 of Visual Assist X (if using Visual Studio 2010) You must use Version 1862.1 or higher of Visual Assist X
- UnCodeX
- [download id="8" format="1"]
This video comes in two flavors. The first video is for people who are brand new or have no idea whats going on:
This second video is a much shorter rapid fire approach to the above, and is either for those without patience or who already know what they are doing but would just like to get Visual Assist X working properly:
Thursday, January 5, 2012
Composing Game Music
Game music is, without a doubt, one of the hardest things to break into, ever. To put it into perspective: I had a friend start a band, get the band signed to a label, make an album, toured Europe, then left the band, all while I was still trying to break into the industry.
Unlike artist, programmers, and even sound designers, very few studios actually house full time composers. Your chances are already slim. Small time indie developers make the mistake of wanting a sound designer that can do both sound and music, or a composer that can do sound design. Add that to the fact that the director of the indie project has a brother with a cracked copy of Fruity Loops who now thinks he's Mozart, and you may realize your chances of becoming a game composer, or even working on projects, are less likely.
Frustrating and depressing at times? Yes. Without a doubt.
Does that mean you should give up? No, of course not. But knowing how hard it is will help put things into perspective.
Taking the music aspect out completely, being a game composer is so much more than knowing how to write music. Dare I say it's an art to itself. Understanding interactive media and how that translates to the music is one of the differences that sets it apart from any other media. You're not just writing a piece of music. You're writing music that has to adapt and change with the player. Not only is it interactive but you have to understand that it is fluid, not abrupt stops from the ambient piece to the tension track. It has to evolve from one to the other. Which, in reality, might be a whole different "transition" piece you have to write all together. Being a game composer means understanding all of this and being able to write music according to these demands.
The Unreal Development Kit (UDK) / Unreal Engine 3 (UE3) and WWISE / FMOD are probably the best examples of how a game engine (or middleware in some cases) create an interactive musical landscape. If you do not understand at least the basics of these programs, and how they relate to, and handle, music you are doing yourself a disservice.
Do you understand when the tension track is played in UDK? How about the action track? Do you know how loop points get set in WWISE, how it can relate to your music, and how it's incorporated into UDK / UE3?
If you have no clue what I'm talking about or don't know the answers to those questions then I suggest downloading both UDK and WWISE and experimenting with them.
UDK Website
WWISE Website
Both are free to download and learn.
Not only will this give you an understanding of how these tools work but it'll give you a better understanding of interactive music. How it's created, applied, and possibly even change how you write you music all together.
Now on to the music aspect.
If you want to sound like Zimmer, do sound like Zimmer, or only write music that has staccato strings with horns playing fifths, and don't even know there's a woodwind section to an orchestra, then don't waste your time trying to break into the industry. Zimmer clones are a dime a dozen and, honestly, not very well-respected in the musical community. Yeah, you might pull off a convincing Zimmer sound, but no one cares. We've all heard that style time and time again.
On a similar note, if all you write is "un-tis", house, techno, whatever you want to call it, you might want to try a different industry as well. Everyone with their cracked copy of Fruity Loops is a "producer" and can write that same stuff. They too come a dime a dozen.
I can hear the angry mob forming, ready to lunge at me with their pitch forks and torches. I know it's very blunt and may even be hard to hear. But the fact is, you're applying for an industry that has some of the most talented and creative people you'll ever be given the chance to talk to or associate with - people who aren't a dime a dozen and could probably write that same generic crap ten times better than you in their sleep.
Do you think Kevin Riepl knows what notes are in a B minor scale? Without a doubt. Do you think Sascha Dikiciyan uses stock presets in Massive? Far from it. These guys have honed their craft and are damn good at what they do. Jesper Kyd, Sam Hulick, etc, these are, essentially, the same group of guys you'll be applying against (or possibly even working with). What are you going to do if someone tells you, "Alright guys, we're gonna write this whole soundtrack in A minor." and you don't know what A minor is, or what notes belong in that scale? (Red Dead Redemption's soundtrack was all in A minor)
Again, this isn't musical elitism. This is knowing your craft inside and out and being able to deliver on all fronts when asked.
So if you are reading this and are becoming depressed - good. But that doesn't mean don't try to break into the industry, just know that it's something extremely hard to do and you really have to be on top of your game to get that foot in the door. Hell, things are just now starting to come around for me after many years of determination and growth.
- David Mason
Unlike artist, programmers, and even sound designers, very few studios actually house full time composers. Your chances are already slim. Small time indie developers make the mistake of wanting a sound designer that can do both sound and music, or a composer that can do sound design. Add that to the fact that the director of the indie project has a brother with a cracked copy of Fruity Loops who now thinks he's Mozart, and you may realize your chances of becoming a game composer, or even working on projects, are less likely.
Frustrating and depressing at times? Yes. Without a doubt.
Does that mean you should give up? No, of course not. But knowing how hard it is will help put things into perspective.
Taking the music aspect out completely, being a game composer is so much more than knowing how to write music. Dare I say it's an art to itself. Understanding interactive media and how that translates to the music is one of the differences that sets it apart from any other media. You're not just writing a piece of music. You're writing music that has to adapt and change with the player. Not only is it interactive but you have to understand that it is fluid, not abrupt stops from the ambient piece to the tension track. It has to evolve from one to the other. Which, in reality, might be a whole different "transition" piece you have to write all together. Being a game composer means understanding all of this and being able to write music according to these demands.
The Unreal Development Kit (UDK) / Unreal Engine 3 (UE3) and WWISE / FMOD are probably the best examples of how a game engine (or middleware in some cases) create an interactive musical landscape. If you do not understand at least the basics of these programs, and how they relate to, and handle, music you are doing yourself a disservice.
Do you understand when the tension track is played in UDK? How about the action track? Do you know how loop points get set in WWISE, how it can relate to your music, and how it's incorporated into UDK / UE3?
If you have no clue what I'm talking about or don't know the answers to those questions then I suggest downloading both UDK and WWISE and experimenting with them.
UDK Website
WWISE Website
Both are free to download and learn.
Not only will this give you an understanding of how these tools work but it'll give you a better understanding of interactive music. How it's created, applied, and possibly even change how you write you music all together.
Now on to the music aspect.
If you want to sound like Zimmer, do sound like Zimmer, or only write music that has staccato strings with horns playing fifths, and don't even know there's a woodwind section to an orchestra, then don't waste your time trying to break into the industry. Zimmer clones are a dime a dozen and, honestly, not very well-respected in the musical community. Yeah, you might pull off a convincing Zimmer sound, but no one cares. We've all heard that style time and time again.
On a similar note, if all you write is "un-tis", house, techno, whatever you want to call it, you might want to try a different industry as well. Everyone with their cracked copy of Fruity Loops is a "producer" and can write that same stuff. They too come a dime a dozen.
I can hear the angry mob forming, ready to lunge at me with their pitch forks and torches. I know it's very blunt and may even be hard to hear. But the fact is, you're applying for an industry that has some of the most talented and creative people you'll ever be given the chance to talk to or associate with - people who aren't a dime a dozen and could probably write that same generic crap ten times better than you in their sleep.
Do you think Kevin Riepl knows what notes are in a B minor scale? Without a doubt. Do you think Sascha Dikiciyan uses stock presets in Massive? Far from it. These guys have honed their craft and are damn good at what they do. Jesper Kyd, Sam Hulick, etc, these are, essentially, the same group of guys you'll be applying against (or possibly even working with). What are you going to do if someone tells you, "Alright guys, we're gonna write this whole soundtrack in A minor." and you don't know what A minor is, or what notes belong in that scale? (Red Dead Redemption's soundtrack was all in A minor)
Again, this isn't musical elitism. This is knowing your craft inside and out and being able to deliver on all fronts when asked.
So if you are reading this and are becoming depressed - good. But that doesn't mean don't try to break into the industry, just know that it's something extremely hard to do and you really have to be on top of your game to get that foot in the door. Hell, things are just now starting to come around for me after many years of determination and growth.
- David Mason
Monday, July 25, 2011
Jump or Die Released!
iTunes Link
In my final quarter at my college, I need to have three completed games in my portfolio to graduate. While I am working on a rather large project that takes up most of my time, I decided that to fulfill this requirement I would make two really simple games. I present to you the first of those two games: Jump or Die. Jump Or Die is a very, very simple side-scrolling 'platformer' built with the ridiculously robust UDK. Sure, UDK is complete overkill for a game like this but because I've spent the majority of my recent time in UnrealScript, I felt it would be fastest for me to make it with UDK. Even for a very simple game like this, I've still had my share of problems that I had to work through and learned far more than I intended, as this was supposed to be a 2-day game max. The odd little quirks that had to be overcome to make this is a discussion for another day, and so now here is info about the actual game.
Jump Or Die
You are a blue box racing for your life.
You must jump over everything in your way and reach the end.
Tap the screen to jump, tap and hold in order to jump higher and further.
Available in English, French, German, Italian, and Chinese
iTunes Link: http://itunes.apple.com/us/app/jump-or-die/id449394637?ls=1&mt=8
Yeah, the game description says it all.
If you decide to buy a copy, take solace in the fact that you're helping me, a fellow UDK'er, to do bigger and better things, and if you like the game, well, BONUS!
iTunes Link
In my final quarter at my college, I need to have three completed games in my portfolio to graduate. While I am working on a rather large project that takes up most of my time, I decided that to fulfill this requirement I would make two really simple games. I present to you the first of those two games: Jump or Die. Jump Or Die is a very, very simple side-scrolling 'platformer' built with the ridiculously robust UDK. Sure, UDK is complete overkill for a game like this but because I've spent the majority of my recent time in UnrealScript, I felt it would be fastest for me to make it with UDK. Even for a very simple game like this, I've still had my share of problems that I had to work through and learned far more than I intended, as this was supposed to be a 2-day game max. The odd little quirks that had to be overcome to make this is a discussion for another day, and so now here is info about the actual game.
Jump Or Die
You are a blue box racing for your life.
You must jump over everything in your way and reach the end.
Tap the screen to jump, tap and hold in order to jump higher and further.
Available in English, French, German, Italian, and Chinese
iTunes Link: http://itunes.apple.com/us/app/jump-or-die/id449394637?ls=1&mt=8
Yeah, the game description says it all.
If you decide to buy a copy, take solace in the fact that you're helping me, a fellow UDK'er, to do bigger and better things, and if you like the game, well, BONUS!
iTunes Link
Monday, January 31, 2011
Global Game Jam 2011
Design and build a game in 48 hours.
I was there last year, I was there this year along side An-Tim Nguyen, Cordell Felix, Michael Sanchez, Samuel Gonzalez, Evan Hill.
iPod + iPad + Kinect game with UDK
I was there last year, I was there this year along side An-Tim Nguyen, Cordell Felix, Michael Sanchez, Samuel Gonzalez, Evan Hill.
iPod + iPad + Kinect game with UDK
Thursday, January 20, 2011
Tuesday, January 18, 2011
Kinect Controller
I bought a Kinect controller. It ships soon.
I don't own an Xbox 360.
This should be fun.
I don't own an Xbox 360.
This should be fun.
Thursday, November 25, 2010
VOTE FOR WARM GUN NOOOOOOOOWWWWWWWWWWWW
So for the past 3-4 months I've been working as Lead Programmer for Emotional Robots, Inc on UDK-based game Warm Gun.
Its a post apocalyptic post World War 3 Old Wild West + a bit of steam punk multi-player shooter.
It only takes one click to vote, however if you're extra nice you'll register/login an account as registered account votes weigh more than guest votes. Also, there can only be one guest vote every three minutes so if it is saying you can't vote, just watch our trailer as someone just voted right before you did! Each person can only vote once though, so tell you're friends and family! Please!
VOTE HERE VOTE HERE VOTE HERE VOTE HERE
VOTE HERE VOTE HERE VOTE HERE VOTE HERE
VOTE HERE VOTE HERE VOTE HERE VOTE HERE
VOTE HERE VOTE HERE VOTE HERE VOTE HERE
VOTE HERE VOTE HERE VOTE HERE VOTE HERE
HERES A TRAILER NO WAY:
Warm Gun teaser trailer - Indie DB
Its a post apocalyptic post World War 3 Old Wild West + a bit of steam punk multi-player shooter.
We need you to vote for us for the Indie of the Year 2010 award at IndieDB.com! At the time of this writing we are rank 27 out of 2,661. Just a few more ranks and we can be listed on the front page as one of the popular games!
It only takes one click to vote, however if you're extra nice you'll register/login an account as registered account votes weigh more than guest votes. Also, there can only be one guest vote every three minutes so if it is saying you can't vote, just watch our trailer as someone just voted right before you did! Each person can only vote once though, so tell you're friends and family! Please!
VOTE HERE VOTE HERE VOTE HERE VOTE HERE
VOTE HERE VOTE HERE VOTE HERE VOTE HERE
VOTE HERE VOTE HERE VOTE HERE VOTE HERE
VOTE HERE VOTE HERE VOTE HERE VOTE HERE
VOTE HERE VOTE HERE VOTE HERE VOTE HERE
HERES A TRAILER NO WAY:
Warm Gun teaser trailer - Indie DB
Allar's Dev Diary #16: Day 7, Tower Defense Side Project
Day 7 (11/24/2010)
12. Getting Towers to Track Their Targets
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.
Tuesday, November 23, 2010
Allar's Dev Diary #16: Day 6, Tower Defense Side Project
Sorry I'm 7 hours late with this posting, had to do some stuff.
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. <_<
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. <_<
Monday, November 22, 2010
Allar's Dev Diary #15: Day 5, Tower Defense Side Project
Day 5
10. Basic HUD Design
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.
Sunday, November 21, 2010
Allar's Dev Diary #15: Day 4, Tower Defense Side Project
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.
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.
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.
Saturday, November 20, 2010
Allar’s Dev Diary #14: Day 3, Tower Defense Side Project
Day 3 (11/20/2010)
7. Aiming With The Mouse
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:
Friday, November 19, 2010
Allar’s Dev Diary #13: Day 2, Tower Defense Side Project
If you don't know about my Tower Defense Side Project, please read Day 1 here.
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:
[csharp]//DefaultInput.ini
.Bindings=(Name="MiddleMouseButton",Command="AllowCameraMovement true | onrelease AllowCameraMovement false")
.Bindings=(Name="MouseScrollUp",Command="HandleMouseScroll true")
.Bindings=(Name="MouseScrollDown",Command="HandleMouseScroll false")[/csharp]
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.
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:
[csharp]//DefaultInput.ini
.Bindings=(Name="MiddleMouseButton",Command="AllowCameraMovement true | onrelease AllowCameraMovement false")
.Bindings=(Name="MouseScrollUp",Command="HandleMouseScroll true")
.Bindings=(Name="MouseScrollDown",Command="HandleMouseScroll false")[/csharp]
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.
Allar’s Dev Diary #12: Day 1, Tower Defense Side Project
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.
Also, I may or may not be live streaming my desktop. http://www.livestream.com/awesomeallar
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. :D
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.
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.
Also, I may or may not be live streaming my desktop. http://www.livestream.com/awesomeallar
Day 1 (11/19/2010)
1. The Design Document
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. :D
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.
Thursday, November 18, 2010
Allar's Dev Blog #11: Pathing Fail
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.
Wednesday, September 29, 2010
Allar's Dev Diary #10: Parallax Occlusion
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.
Subscribe to:
Posts (Atom)