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! :)


Leave a Reply

Your email address will not be published. Required fields are marked *