Category Archives: NeuroPulse

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.

NeuroPulse! Working on the alpha.

So it’s been a long time.

I heard about Microsoft’s Imagine Cup (www.imaginecup.com), and me and a friend thought, “why not?”. So we picked up C++ and got down to it, and so far it’s been a really fun ride!

First the game idea, NeuroPulse. It’s an idea I had ages ago, but since we started thinking it through it’s changed a lot. You can think of it like a neural network simulator with an RTS built on top, or something like that. The basic idea is that there is an environment, and the way you do things is by working with the environment, and of course pushing the environment to do what you want it to do more. Nodes are the main objects in the game, where energy goes and they also emit pulses once their internal energy is over a certain threshold. Certain nodes have a reactor, so they constantly generate a small amount of energy. From this comes out a hopefully emergent behaviour of the whole system. You control nodes by building a hub on them. Around the hub you can build buildings that do stuff and modify incoming or outgoing pulses. The way you build on another node is by sending pulses with building instructions attached, to build a hub, and then afterwards you can just build more buildings easily. To capture an enemy node, you first need to overload the node, by sending lots and lots of energy. Each overload will damage all buildings on a node, until they’re destroyed, at which point you can send your build instructions to the node.

We’re using the Ogre3d engine for the display, and it has been a suuuper awesome ride with it! Really easy to set things up and get going, so we’re really happy with that. And now it’s all about tying in a GUI and some interaction with the whole system and stuff.

Next time I’ll try upping some screenshots!

P.