Category Archives: Zombie Game

New stuff: NeuroPulse and Umbrak

Boy has it been a while. I have a habit of not having a habit of posting here. Lots has happened though, so I hope this will be a mildly interesting read!

First off, NeuroPulse! Me and my good friend Edib0y (that’s a zero) have been working on the prototype, and you can see what it looks like:

We have a Tumblr sort of going, but as NeuroPulse progresses, so will the blog. Important though, is the latest post, which is HERE. Read through that to get a better understanding of what NeuroPulse is and isn’t, and our hopes and plans for its future! I’ll post a few theory things and thoughts I have going on about it here, but mainly we’ll try to keep everything NeuroPulse related over there!

A bit of technical meat, NeuroPulse is based on the Ogre3d engine, using CEGUI as its GUI front-end, and an entity system as its game logic backbone. So far, everything is coming along pretty neat, though we’re in the middle of a big refactoring, which I should finish soon…but I’ve been sidetracked…

Which brings me to the mysterious name, Umbrak! 2 days ago I got the urge to make a small, little, quick, fast horror game, but as everyone who’s ever developed a game knows, that doesn’t happen. I started programming, dropped in my entity system, dropped in my screen system, but still a lot of the engine meat was incomplete. So I got started on that, but also wanted to focus as much as possible to make it easy for me to change things, add things, etc., and so I ended up with 2 fancy dev tools in the engine.

First thing I implemented was live asset reloading, which means that I can reload all dynamically loaded assets whenever. In the game engine, when it reloads graphics, it will replace those graphics as soon as they’re loaded, and so I can swap out graphics for new graphics without even restarting the level I’m testing, which should be really handy for artists who need to have that one thing look just right in that one spot. This has a ways to go in terms of optimizing the graphics, like baking all static assets onto a bitmapData, but so far so good!

Next thing I went to do was implement scripting! I used hscript, which is a scripting language for Haxe, and it looks like Haxe, and works like Haxe…so in my scripts I’m very free in what I can do, the only limit is I can’t declare new classes, and other things which are listed on the hscript gcode page. What does this mean? First off, I have a little console through which I call the asset reloading functions, world reloading, screen reloading, etc. etc.. I basically have everything accessible to me, and I plan to implement simple level editing capabilities too.

Then, I also use scripting for world initialization, as well as object creation. The world initialization declares object types, and the associated scripts it should use when finding such an object, and object scripts simply setup the entity with all the components. It has actually proven to be pretty useful and dynamic, since I can easily change the radius or brightness of a light, reload the level, and bam, see the changes applied! In fact, another thing I plan to do is make it so I can reload specific object scripts, so I don’t even need to reload a level to see changes applied to updated objects! Snazzy…

Oh, and why Umbrak? Well, I was thinking horror game, so naturally what came to mind was Penumbra. Which went to Umbra, and thought that sounded too simple so I added a “k”. Not sure if it’ll actually turn into something, but time will tell! Screenshots would be a bit pointless, since it’s basically my lighting engine patched together with NAPE physics, but if things get interesting, I’ll try and show something!

As always, if you happen to be reading this, and have a question, comment away! :)

P.

Dynamic 2D Lighting

[UPDATE 27.01.15] Interestingly enough, while cruising these old posts, I found a link to this post which also might have some useful explanations on the concept.

So I finally got down and dirty last night, writing a new dynamic lighting library from scratch, and really trying to do it right. Well, today I have the results! :) I will still be optimizing the lighting engine further by using memory access, which should speed up line drawing considerably, but all in all, it’s running pretty fast!

You can see a demo here: (There aren’t any actual objects, only shadows)

Dynamic Lighting Demo (Click the picture for a live demo)

It has 3 lights and 100 squares placed randomly on the stage (2 of the lights are moving). The 100 squares are technically polygons, so you can construct any polygon you want from a series of points, convex or concave, or it doesn’t even need to be a closed polygon, it can be just a series of lines.

The way I made this is actually really simple:

First I store a canvas for each light, on this canvas all the shadows for that light will be drawn, and it will be used as an alpha mask for the copyPixels() of the lights texture onto the master canvas. When drawing an object for a light, I first tell the object to draw itself onto the light’s canvas, and to return all of it’s edge points:

For each point in the polygon, I get the vectors from the light to the current point ( vc), a vector from the light to the next point ( vn), and a vector from the light to the previous point ( vp). To determine if vc is an edge point, I need to check if vectors vn and vp are on the same side of vc, or on opposite sides. I can do this by using a 2D cross product between vc and vn, and between vc and vp. If  vp and vn are on opposite sides, their cross products with vc will be of opposite signs, the same if they’re on the same side. So for a tiny bit of math:

var vc = { x: current.x - light.x, y: current.y - light.y };

var vn = { x: next.x - light.x, y: next.y - light.y };

var vp = { x: previous.x - light.x, y: previous.y - light.y };

var crossN:Number = vc.cross( vn); // cross product

var crossP:Number = vc.cross( vp);

if ( crossP * crossN >= 0) // the current point is an edge point

We can further use the result of crossN to see whether the segment we are going to draw from vc to vn is facing the light source or not. If the vertices of the polygon were specified in a clockwise order, then crossN will be negative if the segment is facing the light source, positive if it is not. In the light demo above, I only draw the segments that are facing away from the light source, so that most of the object is exposed to the light, but this can be easily changed.

After the edge points are found, I draw a line from the edge point, to the edge of the light’s canvas, essentially a “shadow” of the point from the light source. These lines combined with the lines of the object, will form a polygon of shadows on the light’s canvas. From there, we can floodFill() in the center of the canvas to fill the lighted area, and from there, copyPixels() the appropriate part of the light’s canvas to the main canvas (which would generally be the size of your screen).

Some improvements to be made are to support circles as shadow casters, as well as optimizing floodFill(), since that is the current bottleneck, not sure if that will be possible though.

I realize that I suck at explaining stuff like this, so if there are any questions, ask away! And I’ll try sticking this lighting engine in the Game Jam game this weekend, hopefully it will make stuff look a bit better. :)

P.

NG Game Jam 8

SO!

I never write here anymore…and I always say that’s going to change…so no promises on that in the future.

Anyways, to the point. Last weekend I took part in the Newgrounds Game Jam 8, with my partner, Nicholas Deary. We both have worked together in NG Jams before, about 3 times together now, so we are starting to get to know each other pretty well in terms of working and mindflow. Interestingly enough, right after game jams, we usually just go back to our own business and start messaging each other again only right before the next jam!

This time that’s changing a bit, since we didn’t finish our game for the game jam deadline, even though the game engine is working almost 100% as we want it to. All that was lacking was content, in terms of puzzles, and art, and a point to the baddies, which all they did was run at you, if they hit you, you saw static for a bit, otherwise they just disappeared after 5 seconds.

Here are 4 screenshots of the current engine:

Screenshots x 4 of the game engine.
Screenshots of our game, which will hopefully be finished next week!

Currently you can walk around, look at certain things, pick up items, and toggle switches (open doors). Might not seem like a lot, but each item and switch can have a required item to pick it up/use it. Also, switches can be linked to multiple doors, with either open, close, or toggle commands, which gives us a chance to make puzzles in getting the right order or switches or something. It isn’t a lot…

But that’s why we’re going to jam things up this coming weekend again, and stick in a few more features, and prepare a proper level to explore and do stuff in! Additional things I want to get running from the engine side is switches not only open doors, but switches themselves having an active state, and they can be a requirement for picking up items or using other switches. And switches to have different types, like a user activated switch or auto switch, that activates when the player, or other entities are nearby. And also if it’s a toggle switch or a momentary switch (while standing on it, it’s on, when you leave, it’s off). This will already multiply the possibilities of different puzzles, especially if you need to use the bad guys to solve certain puzzles!

The whole take I’ve had on this project is not as an action top-down shooter, but much more like a puzzle game, with horror elements. Right now the horror is working out okay, but sound work as well as an improvement on the gfx should help. While you can do it, there is currently no point in equipping items, as you need to use them from the inventory with your mouse on other objects. I might change this to having to equip and hit other items to use it, if anyone actually reads this, they can leave a comment below suggesting something! :)

I have thought about doing pop-up puzzles, or password entries, and I’m starting to think it might be out of scope for the current game, but in the future, you can count on it!

A funny afterthought about this whole game jam thing….I’ve been working on and off on my zombie game engine for the past few months, with pretty good results. This last weekend I created a whole new engine (with a few parts tugged off of the zombie engine) in under 48 hours, and it is already better than my zombie engine in terms of features. This means that the old zombie game project is off, and I will be continuing work with this engine in the future. I think it is a really good base, since it also made improvements on level editing in Flash (it now parses a textfield that should contain a JSON object to give objects properties).

Pfff…anyways…if anyone is reading this, thanks for reading all the above, I guess it’s kind of a long read. Any questions? Comment below!

P.

Gears are creaking…

Haven’t updated this place in ages, but then again, I highly doubt anyone reads it anyways.

But for the sake of having a blog, here’s an update on things:
I’ve been super busy.
Music “career” had a small boost, record label and whatnot, but nothing too huge yet.

Zombie game is back on!
I restarted the engine from scratch redesigning the architecture like mad. It’s making working with the engine much easier, plus I’m using the NAPE AS3 physics engine to handle collisions, and so I should have more features than initially planned, and overall it’ll hopefully look very shpamtastic.

So far where I’m at is having the physics running and just boring engine stuff. Still have some things to sort out with weapons and object spawning in general…can’t figure out a good way to stick it all in and keep everything nice and clean between classes.

I’ll up a demo as soon as I get something interesting going, but a big feature add is the ability to drag objects in the game (thanks to using a physics library). I’ll probably be using that a lot for puzzles and also to hide from/block zombies (Penumbra/Amnesia style, except 2D)

Humdumdum…I guess that’s it for now. I’ve been working on a snazzy tech demo for some dynamic grass, not sure if that’s worth uploading yet either. But depending on how much I can optimize it/make it work, one more treat to be seen in the zombie game! It gets a very nice moving atmosphere.

Till next time, hopefully in the next month you’ll be seeing some stuff. And by “you’ll” I mean the Google web crawlers who are probably the only ones who check out my blog.

P.