Here are the things I’ve just done…
- Added a new light, the velocity light, which either increases or decreases the velocity of anything under it
- Added bullet animations and artwork and a flash animation for when they hit things
- Added a flashing light to the enemy that flashes and rolls at you
- Added an explosion animation for enemies when they get shot
- Added working 3D sound to enemy sound effects
It’s funny because none of these things were particularly challenging or time consuming, but the game seems way different now that it looks like something. Up until this point, I was playing the game with the debug view from the Farseer Physics Engine on, but now it can function as a visual element without physics debugging to show what’s happening in the physics world.
I am going to start expanding the level I have, adding some actual platforming, and I have been asked by classmates multiple times about adding a light that the player can control, so that seems like an obvious step to take. Moving platforms are something I’d like to have as well. It still isn’t that pretty, but I guess I need to get a video up of what it looks like. I know there are some friends that would love to play whatever I’ve got too, and I’ll make that happen this Thursday to get some advice on where I should go next, and of course to just get some end-user opinion.
I have some news about other projects that I’ll be posting about soon.
I just finished using XACT to create an RPC curve that is used with a distance variable to provide “3D” sound as an enemy approaches the player. Of course the game is 2D, and all I’m really doing is tweaking volume based on distance, but it’s a nice effect and very easy to do once you understand how to use XACT. I also added a shooting sound effect, and next on the list is to add animations for enemies being destroyed and bullets hitting things. I also want to integrate a couple of cool sprite sheets I found into the current test level to see how they look, and hopefully have a more visually appealing demo. Last time I played with creating level artwork I had a terrible visual issue in which tiles had line artifacts in-between each other; I might run into that again, and will have to spend some time figuring it out if that’s the case. I know it has to do with how scaling affects the sprite drawing, but I’m not yet sure what the remedy is.
So my work with Processing turned out to be immediately helpful in my XNA work; one of the things I did with Processing was create a sort of player that had a few different states with corresponding animations, so I basically ported that idea over to my Ne+ player. Now I have walking under its corresponding animation, and sprites for standing, jumping, falling, and crouching. I think that crouching is turning out to be pointless right now, although only because I’m not moving the physics object in such a way that it would dodge anything. I’m not going to worry about it at the moment, it can be a purely visual thing for now. The next thing I did was create a simple sprite for bullets, and start attaching lights to them as well. I hit a snag that I thought might be a Krypton issue for just a moment, but really what the problem is is that I am currently letting the player hold fire and shooting a bunch of bullets; the lights overlapping made them look like big red circles rather than a lit area, and I spent a couple moments tweaking Krypton values before realizing I just needed to add some limitation to the firing.
The new project I’ve started in Processing is going extremely well. I did have a bit of a rough time last night; I stayed up until 3AM figuring out how to make a project that would work in both Eclipse and the Processing editor, as well as provide me with a workable workflow. I still haven’t really figured it out; basically I need to keep the library I’m developing for it updated in two places. I’m sure I could write an Ant script to do this for me, but ugh… and the Processing plugin is okay, but for some reason I’ve lost out on autocompletion in the sketch files. I don’t know, there’s a couple issues I still have, but I definitely know what needs to happen to make everything work in the meantime. I should mention that I made a big step as far as deployment goes too; it’s another process I’m not entirely happy with, but after I follow it I am basically able to deploy whatever I’ve done to a blog post. I should also mention that it didn’t work on Internet Explorer… I’m sure there’s a solution for that, but… I’m just not going to deal with it right now.
Isn’t that interesting? Now I can develop things and then put them on my website! Of course we all knew this was possible, but I had just avoided diving into Java and Processing until now. I even ported over the component system that I’m using in Ne+ and have a sprite library that should handle animations for me, although I haven’t made an animation to test with, and I also polished the dialog box I made so that it works pretty well. I still need to figure out how I’m going to make the little triangles that come out of it and point at who’s talking… What could I be up to, I wonder?
I was rather unproductive this week, thinking about what I was going to do and not getting around to it. I also had a lot of paperwork to take care of due to a new job that I will be starting in the Spring, so that left me not wanting to do much else. But! Now this the time for action, because I definitely don’t want to be left with a bunch of work to do when I have to start a full-time job! So, here is my basic rundown of stuff that I want to have accomplished by the end of this sprint:
- First, smooth out the two enemies I created and add an animation for the one that currently doesn’t have one
- Fix a bug wherein the flying enemy falls to the ground (has to be a simple logic error)
- Actually, I just looked at the code and that stupid bug was because I had already set up a timer which tells the enemy when to attack, but never actually implemented attacking, so a nice block of nothing was getting executed after a certain amount of time
- Player-controlled light or enemy-controlled light? I guess player-controlled would be the more “fun” one, so I’d be a fool not to do it. Mouse used to point in certain directions, or else arrow keys
- Player sprite! This can’t be put off any longer, the player needs to look like something or there isn’t a game
- Add new lights, this should be easy, just need to do it.
- Expand the levels, throw in more enemies
- I’m still debating this one, but a way to write messages to the screen, and have NPCs to talk to? This seems like it could be helpful for content, and also for future projects, but at the same time I kind of want to avoid it. Need to think more about this.
- Create a cutscene. Really want to do this, but if it doesn’t work out I’d be okay dropping it
So that’s a good list to work with I think. Really need to have something for people to play. And in the meantime I will try to get this thing running on foreign machines; I want to be present for the process so that I know exactly what end users have to go through.
NOTE: For better or worse, the following is a bit of a live development journal of working with the flying enemy that dives at you.
I just was working on the flying enemy that is supposed to dive at you, and implementing the attack method the first try he flew up instead of down at you, and the second try he just got onto me really fast and shoved me against a wall. Pretty brutal, pretty awesome actually, but I think it was most awesome because it was so surprising to me. Man, just tried it again and if you jump, the thing pins you to a wall and you slowly slide down it together while it’s pushing you against it. So awesome! However, now it’s very clear that I need a way to know when the player has been successfully attacked. Sounds like more collision subscription to me! Of course that would be the case.
Rather big progress today, actually. I created another enemy that rolls at you, and I also created a bullet class and physics component, and added collision category support so that everything which collides with other things has well-defined properties. I also added “crouching” to the player, so that you can fire at two different heights. The bullets work flawlessly with the gravity light, which makes them angle upwards. This could be used to shoot the enemy that flies above you. I want to add artwork to the rolling enemy so that I can call it done, and I need to add the concept of health to the player. The enemies have health, but the player isn’t affected by them yet. Next steps are to limit the amount of bullets and make each key press fire only one bullet, and also to add artwork to the bullets and perhaps a little explosion animation when the bullet is destroyed. And then I want to create more lights, finally, now that everything is working pretty well. I will make a firm decision on which lights to move forward with shortly.
I’ve been coming to grips with the fact that the enemy movement is not precisely as simple as I thought it would be. That said, I have got a pretty nice enemy that flies around above you without too much work, but the movements are not yet smooth, and it’s a bit weird because I’m applying forces to a physics object rather than simply updating position. It also doesn’t try to attack yet, and I also haven’t implemented the collision stuff that will handle damage and other effects of collision, but that shouldn’t be too difficult. I will be looking around online for different techniques to approach the enemy movement with and see if there are any good ones I should know about.
I also still need to implement projectiles for killing the enemy with. In its current state, the enemy won’t be easily shot unless it is trying to attack, or if the player can aim all around the screen. For now, simple left and right shooting is going to be the name of the game…
One of my goals this week was to get parallax scrolling working, by importing TiledLib’s draw code into my Level class and adding some features. Now, any layer that I mark as a parallax layer can have a value assigned (right now 0.5 and 1.5 are the values I’m working with, and they just represent scroll speed as compared to the main level layer that the player traverses), and then the draw code will take care of the rest. Really easy stuff, actually, but it did take me a while to see exactly how I was going to add it. I exposed player position in the engine so that the level could draw itself accordingly… it’s definitely not the most elegant solution, but it got the job done for now and I’d like to keep pushing forward.
Currently, I’m in the middle of working on the player class. It just got a lot more complex without much extra code, because now I am actually using the wheel that I had my player’s main box sitting on. Up to this point, I was using it simply to smooth traversal over platforms that were directly next to each other, because jerky movement occurred when something like a square with harsh vertices hit the seams. But now, the movement is defined by rotating that circle, rather than simply applying a force pointing left or right, so I instantly get a couple of neat effects – first, if the player jumps, it isn’t possible to move in the air, because all that will be happening is the wheel rotating in the air. I do want the player to be able to move a bit in the air so I’ll define some special cases for that, but the feel of the movement seems a lot better to me now.
For now, I am going to define a standard jump height and then not let the player jump again until back on the ground, because right now it’s just possible to float forever. I might keep that in as a debug option for myself, because it’s nice to be able to go anywhere, but I’d like to be pretty much done with the player class for now, so after I get the air movement and jumping taken care of I’ll move on to some more new light classes, and parallax scrolling with some background and foreground art to spice up how things currently look.
I went ahead and re-worked how I was implementing light effects, and I think that now I have a much better system going. Basically Farseer lets me define a fixture that is defined as a “Sensor,” and I hook into collision events so that I can call a function every time an object enters or leaves a light. Using those, I maintain a list of fixtures that are currently under a light, and can apply whatever forces or manipulate whatever attributes I want with every fixture on the list. Next up is to get the null light working again, and then I’ll be in pretty good shape for starting to create new stuff.
UPDATE: Score! That wasn’t too bad at all. Now I’m back to the functionality I had before, but it’s more extensible and more stable than it was before.