It's Been Awhile! - GDDs

Hello! It's been awhile since my last post. Sorry about that! So, I've been working on Valchion here and there (as well as other things, as always), and I really would like to finish it. Something I've found particularly useful is a Game Design Document.

What's a Game Design Document (or GDD)?

To me, a GDD is basically a plan for how a game is supposed to function, and how it works. Basically, you write out a GDD to explain what the gameplay's like, or what the plot revolves around, and what elements you plan to add and how to do so. Basically, GDD is a general document detailing the overall design of the game. Check out this Wikipedia link for more specific information on what a GDD is.

Why is a GDD helpful?

A GDD is helpful because it helps you out with two things.

1) It reminds you of what the game is supposed to be.

Without a GDD, it can be difficult to keep straight exactly what the original idea behind your game was. For example, without a GDD, you may not be able to remember how many zones there were supposed to be in the game, or what the general size and structure of the game was like. The other thing a GDD does is:

2) Keep you from adding things that don't line up with that original vision.

It's easy to get distracted while developing a longer-term title, and find that you stumbled upon yet another cool, new gameplay element, or an idea for another level that works better than the ones you have currently. The GDD helps you to stick to the ideas you have down already, rather than chase new features and content. Now, there's nothing wrong with finding a better way to implement a feature, or even to replace major sections of  the game based on ideas and the general feel of the gameplay. However, the GDD should reflect the current goal of the game. If you have ideas and "updates" that you want to apply to the game, then you should update the GDD accordingly, so that you don't get distracted, and can really focus on pre-determined aspects of the game.

The short of it is, I'm personally finding it a lot easier to work on Valchion when I have a GDD to guide me. With the document, I can get an idea of which zones lead to which other ones, and what pre-requisites there are to access zones (i.e. if you need a certain item). This helps to make the flow between areas easier to understand and build the game world around.

Apart from GDDs, I recently also purchased a cheap little art drawing tablet, so I've also worked on "leveling-up" my art skills. Anyway, thanks for reading!

By: Unknown On 12:50 AM

Continue Reading

[R&D] Unity First Impressions #3 #gamedev

We've in progress with a new Unity #game for mobile devices. Working on gameplay with early #prototype and sharing more first impressions.

We can't share a demo and material on #game it so some funny stuff instead  and more funny stuff in the end of article ;)

1. Development in unity is specified for the desktop, but when it comes to mobile devices, small problems that complicate the process and increase the testing time appear. I wasn’t able to find a way to emulate gyroscope accelerometer data etc. while testing in the editor itself. It all comes down to a long compilation process and then you still need to transfer everything to a devise or an emulator, which also takes more than enough time. Another thing that’s even more uncomfortable is editing the touch events, because they cannot be emulated with the cursor. A problem like that did not exist in the Flash+Starling. In fact, there was even a gesture emulation. Here you need to work with what you have. In other words, to use the keyboard and come up with something else. If you want to check the click through rate of the desktop objects, you’ll have to write a similar code, that reacts to the movement of the cursor with the pressed down button. By the way, if you write a code, optimized for multitouch, for pressing more than one button at the same time, during the reaction realization only one will work. It means that you’ll have to write a code for touch tracking anyway and there isn’t a way to make sure if it works in the editor during the quick launch, only after a long compilation and installation process. Long story short, there’s enough trouble.

2. When working with 2D gui objects, the incomprehensible coordinate system with the beginning in the center of the screen brings more problems. What I mean is that a point, which in the standard screen coordinate system is located in the upper left corner of the screen and its coordinates are (0:0), will have (-Screen.width/2 ; Screen.height/2) coordinates in the unity system. That doesn’t seem to be quite comfortable :) Maybe I just haven’t found a way to change the coordinate origin settings yet and everything is a lot more simpler. By the way, 2d elements can be set in the 3d coordinate system. Then the location on the screen can be measured with the floating point number from 0 to 1 and it automatically redraws after you change the screen size. It’s cool, but not when you need a pixel accuracy.

3. I almost managed to repeat the Flash application structure by operating the process from one class (a sort of Main). To do that, you just need to create an Empty GameObject and attach the code to it.

4. There’s also a lack of such ActionScript feature as the addEventListener. For a class, inherited from MonoBehaviour, there’s a possibility to reload the functions, that are called at specific events. There’s a lot of them (https://docs.unity3d.com/Documentation/ScriptReference/MonoBehaviour.html). You could say, that there’s one for every occasion, including the events, that react to collisions with other 3d or 2d objects, the beginning and the end of render, cursor click etc. However, there’s one negative side: if you need to track an event for many objects on the scene, you won’t be able to do that with a simple addEventListener line in the cycle. There’s more than one way out of this situation, but none of them is that simple. Such solutions aren’t good enough, if you need to quickly create something new and check if it works without fixating on the realization of such mechanism.

5. Unlike the MovieClip with one main class, the object in unity and prefab can have as many classes like that as you like. It’s really cool and handy. You can add a code while the program is running and in flash it was impossible. Access to such class: while in MovieClip we’re working directly with variables and methods, in unity GameObject we’ll have to use the GetComponent function. It looks something like this: (myGameObj.GetComponent("sizeClass") as sizeClass).width = 500;  you can save the link in the variable, so that there’s no need to invoke it every time. It codes well)))

6. The physics is great and simple to use. It saves time during prototype creation and especially things like inert object moving and their collision. Before in most cases mechanics like that had to be written manually or you needed an external framework. Here there’s no additional installations and complications. It’s enough to watch a couple of video lessons to make a judgment about the simplicity of physics http://unity3d.com/learn/tutorials/modules/beginner/physics

We've got a demo, working on features and playability but with unique gameplay can't show it as I've told before. So instead of sketches I thought to share funny and completely unplayable demo of Angry Birds in 3D (Web and Android Builds).

Also I'm still planning to expand Unity on Windows Phone impressions in previous article R&D for Moblile Game Development.

Previous parts of this article are here [R&D] Unity First Impressions #2 #gamedev and here [R&D] Unity First Impressions #1 #gamedev

That’s all for now, see You soon :)

By: Unknown On 8:08 AM

Continue Reading

[R&D] Unity First Impressions #2 #gamedev

We've started up with a new Unity #game for mobile devices recently. Working on #tech demo/#prototype and sharing more first impressions.

1. What I like most is good documentation. The video lessons from their official site were enough for the beginning. Now I’m also watching the lessons here http://www.unity3dstudent.com/category/modules/ . The examples on this site are only on Js. It would seem to be uncomfortable if you want to write on C#, but you can easily write a code of equal value on both languages and the best part is that scripts on unity can be also written on both of them and they will work together without any problems)) I’m not sure yet which language to choose. JS is kind of closer to flash, but C# is easier to read when it comes to large amounts of code. I hope I’ll decide soon.
   
   
2. The most complicated thing so far is to understand the unity application structure itself. At some points it crosses path’s with flash and is complicated by 3d frills. It’s hard at the very beginning, because after working with 2d graphics it was a little unusual that you need to at least set the lights for the scene, or else it will be dark like in… )) After 2d, it’s also hard to allocate objects in 3d space. A simple drag-and-drop with the cursor doesn’t always work. Sometimes you’ll have to switch between different projections and drag the object in each one of them.
    
3. It’s important to understand what prefab is. It’s a MovieClip analogue, only with a more complex structure. I didn’t puzzle out all of the details yet, but they can be easily created on the scene with a simple drag-and-drop as well as with a dynamic code.
   
   
4. What also made my day is that if class contains public parameters, they are shown in fields of object inspector and can be edited manually from there.
   
   
5. I really liked the simplicity of adding physics to the object. It’s quite simple to add a Rigidbody component to the object and it will begin responding to the physics. You can set such parameters as weight, gravity etc. The manipulation with physical factors also doesn’t seem to be quite complicated. For example, gm.rigidbody.AddForce( Vector3(0,20,0)); - is a sort of a way to kick the object up (it will gain a one-time speed-up depending on the indicated vector). There are a couple of more useful things like that, which can come in handy and will save plenty of time for quickly written trash-games.
   
   
6. I also haven’t got the time yet to figure out how you can simulate the accelometer and gyro sensor on your pc. Once again, I’ve spent enormous amount of time on testing one code line, which responds to the accelometer.
   
   
7. In the morning, I heard that a new version of unity with 2d native support was released. I’m curious about what they came up with :)

We've got a demo working demo but with unique gameplay can't show it,  So sketches next I guess.

Also I'm still planning to expand Unity on Windows Phone impressions in previous article R&D for Moblile Game Development

That’s all for now, see You soon :)

By: Unknown On 6:42 AM

Continue Reading

[R&D] Unity First Impressions #1 #gamedev

I'm happy to post much more #gamedev related articles recently :)

We've started up with a new Unity #game for mobile devices and finally it's with unique #gameplay that we invented or mixed to tell more precise.

So working on #tech demo/#prototype and sharing first impressions.

This is our opinion about Unity so far:

1. The coding is bearable, but unlike Flash, all kinds of simple operations are more complex, for example:
something you could spell out in flash like this
mc.z+=10;
here will look like this:
transform.position=new Vector3(transform.position.x,transform.position.y,transform.position.z+10);

2. It’s cool that you can add your code files to each scene object just like it once could be done in the Flash with AS2. It’s kind of a convenience plus, but it’s not clear yet how to cooperate with objects, roughly speaking, from other files.
And where’s the main file of the Main program/class isn’t clear too.
As well it is unclear how to operate with the dynamically created objects.

3. The cell phone development is kind of moronic.
The preview starts up fast, but you’re not able to set a specific screen size, because it depends from the way the panels are arranged and on my monitor it’s really small. The only way to test it with a decent proportion is to prepare a build for either your PC or your phone and indicate the size directly. The problem is that in both cases the build preparation will take lots of time even for a couple of code lines, not to mention the installation time on your phone. In Flash it’s quite simple. All you have to do is launch the adl. It’s quick and the result is almost the same as the one on your phone.
To sum up, it’s kind of disappointing, when all you need to do is change one small line or even one number, but you have to wait for about 5 minutes to see the result.

We've got more impressions written down for the second article, the translation is in progress...

Also I'm planning to expand Unity on Windows Phone impressions in previous article R&D for Moblile Game Development

See You soon ;) 

By: Unknown On 3:08 AM

Continue Reading

R&D for Mobile Game Development

I haven't coded two of our latest games and now, one is on App Store and Google Play, here is browser version with links to mobile and the other is going to be available at FGL pretty soon. Now I go further I haven't tested technologies just set a task, publishing demos, sharing impressions and conclusions :) Now I can be called R&D manager for sure :P

The task is to get our next games workl properly in Browser, on iOS, Android and Windows Phone. The last requirement makes AIR not a variant, so in focus HTML5+JavaScript and Unity. We made AIR/Flash based performance test demo too anyway. Also Visual Studio was involved %)

The laziest and easiest solution is PhoneGap

Pretty easy and nice but performance of 1,5 FPS on Motorola Defi+ makes it not quite usable.

So we've tested natural performance Unity, HTML5+JavaScript/jsFl and AIR/Flash. We havn't find the way how to display FPS in Unity, so will tell that all three variants runs fast in Browser. On Android Unity, Flash, JS works the same as for Browser naturally. Android selected for showcase because no certificates required to run.

And the most interesting case about Unity build for Windows Phone. It's not too trivial and I'll post howto and some results  As soon as I have more time...

[Updated #1] Hello ... :) I've finally found time to launch it, error was in project for Android, clean new project launches fast and easy :) I'll share more info on actual demo run on Windows Phone and Windows Market submission too ASAP  #gamedev

+ Meanwhile one more Unity tech demo and one more in progress, hope we'll have a new game on Unity pretty soon ^)

[Updated #2] Three more articles [R&D] Unity First Impressions #1, #2 and #3 and several tech demos there.

++ Working on one idea how to invent games, don't know have I seen It somewhere or it's or know how, going to share ASAP too :)

By: Unknown On 8:33 AM

Continue Reading

10-16-13 - Valchion Update - GLSL Lighting

Hello! It's been awhile since my last post. I apologize for just disappearing, but life found a way, haha. I've been working on Valchion for the past few weeks, and before that, Sustain.


I'm going to try posting here more often, so that may mean smaller, more bite-sized posts to help me get through them. So, I've done quite a bit with Valchion so far.

I've started moving it over to GLSL (still in the Blender Game Engine) to give it better lighting and dynamic shadows. I thought it might be more efficient than having my own lighting system that needed to be rendered and updated every frame, but that may or may not be the case, as I'm seeing. :S

The lighting really does make the colors pop, though, which is good. I've also implemented a pixellation filter that makes the game look like it was rendered at a lower resolution and then upscaled. It can be triggered off and on in the options menu, which is nice.

I've also changed the bullets back to being just ray-casts, to give that quick and sharp-feeling action back to the game.

One thing that moving to GLSL mode did was make the loading take waaaay too long, so I've changed the way the game worked as far as maps. Previously, there were several maps in a scene (or zone, in a sense), and Blender would load up the scene, and then transfer you to an individual map.

Now, the maps are all hidden in an inactive scene, and the current map is loaded in. When you need to go to another map, it deletes the current map and loads in another. This process reduces the load time jumping between zones, since it's not loading maps that it doesn't use.

Anyway, it's nice, but as you can see in the screen above, the game's eating up my graphics card, which isn't great considering how little I actually have going on so far. I suppose it'll take some more diagnosing to figure out exactly where the issue lies with this.

Thanks for reading!

By: Unknown On 1:46 AM

Continue Reading

Hello Again!

Bullets are now physical objects;
They don't look like erasers like
this picture suggests, though.

Hello, yet again! It's been quite awhile since my last post - sorry about that. I've been really socking it away lately at my game project, which is great news. 


One thing that I've done is go back to Valchion and altered the combat - shooting used to be instant, but I've changed it to be slow, actually visible, dodge-able bullets. The instant ray-cast bullet method worked well, but the combat kind of suffered for it, since you could easily run into a problem with your aiming and easily take a lot of damage for it.

Now you can actually dodge the bullets (as long as they don't
move too fast), which might actually make the combat more fun overall. I feel like the guards might be too stupid, as they just follow you around shooting at you, but I'm not sure - maybe that's fine for 'beginner' guards.

I think I'm going to rework a small bit of the saving system. Before, I was saving basically everything in your inventory, including your weapons, which were Python objects. This meant that any time I loaded a save game, it would actually load the weapons you had at the time of the save into the inventory, regardless of what was in there previously. This means that even if I updated the weapons to have more ammo, or have a higher attack rating, loading the game would override these values. I'll just save the acquisition of the items in the game rather than their actual stats. I remember that I wanted to save the entire item in case I did something with it (i.e. you upgrade your weapons somehow), but I don't think I'll actually end up implementing that idea (for now, at least).

I've also worked on the dialog system a bit to allow for questions, as you can see to the right. I wanted to have more dialog in the game - to have more of a feeling like you're not alone, and of less isolation. Hopefully I'll end up using it well.

Here's a little technical write-up on how the dialog system has been improved:


At first, your average piece of dialogue looked like:

['Hello!', 'I am the second message!']

where it would step through the list index by index. It got more complex with dialogue options, and it was kinda awkward overall. Now I use a dictionary that allows me to do things like jump between conversation points by name, as well as do questions more easily. Here's an example.

{

':start': ['Hello!', 'I am the second message!', 'QYou understand?', ':Ido', ':Idont'],

':Ido': ['Good! I am glad you understand!'],

':Idont': ['Oh, that is too bad.'],

}

The ':start' key is where the dialog begins. It steps through the list and displays the text associated with that key until the end, a string that has "Q" at the beginning, or a string that has a ':' at the beginning.

A string with a "Q" at the beginning indicates a question. The NPC crops out the first "Q" when sending the text to be displayed, of course. The next strings are the labels to jump to if you respond with YES (the first option, one index further), or NO (the second option, two indices further).

Labels have a ":" at the beginning. You can jump to a label by using a string with the name of the label in the text. So, I can do things like repeat loops. For example, something like:

{
':start':["QWill you save our village?", ":SURE", ":NOPE"],
':SURE':['Hurray! Here's a sword!"],
':NOPE':['Oh, no, bro! Are you sure?', ':start'],
}

Should give a continuous loop if you reply with no. I can also change the script depending on the number of times you talk or interact with an NPC, which is nice, too. I might make a video about it soon, though I just outlined it pretty well, I think.



Also, I fixed the text to work better in a window, so that full-screen mode and window resizing should be nicer.

Anyway, I'm also working on another game project - one  reminiscent of the neon arena blaster, Geometry Wars. It's called Sustain (for now), and already feels pretty fun. It'll be an arena shooter like the aforementioned game, but with more twists on the original formula, like unique ships, weapons, and enemies. 

I think I'd like to encourage team-play with it, which is something that never really happened with Geometry Wars. Anyway, I'll write about it when I have something a bit more concrete to show (like a video).

Finally, I made a little video cartoon with the Blender Game Engine. I chose the BGE over Blender itself because I couldn't figure out a way to easily and simply do UV animation in Blender. I do this kind of animation (which can be seen on the character's face and eyes in the cartoon) in my games all of the time, so it was a nice fit for me. Anyway, watch it here!


Thanks a lot for reading and even watching. Have fun!

By: Unknown On 11:16 PM

Continue Reading

BGMC 7 - RFC 5414

Hey! So, I participated in the BGMC 7 and made a quickie little demo called RFC 5414. It was going to be about wireless signals, you being a small robot designated to carry around packages to hotspots, or something like that. However, I ran out of time (and got tripped up a bit with the flight mechanic), so there's no game to it other than just flying around. I'm still glad to have participated, though - I learned some cool things.


One nice thing to come out of it is that I made a Google Code project for my BGE resources, which should be much easier for me to update. Also, I made an input handler, which should make handling input for BGE games much easier. I'll add it to the Google Code project later.

Anyway, here's the download. You'll need a recent version of Blender to play. There are some bugs, most obvious of which is the possibility that the game will spawn you in the middle of a piece of land, so if that happens, just restart. You can use the mouse and keyboard, or a joystick to move around. Space is to jump, and also engages and disengages flight when you're in the air. Hopefully it'll be useful.

By: Unknown On 1:22 PM

Continue Reading

Valchion Devlog Update - 3-4-13

Hello! It's been a little while since my last blog post, but I've been working on Valchion slowly and steadily. It's starting to shape up. Here's a video showing my progress after the break.

By: Unknown On 1:23 AM

Continue Reading

Soldier Of / Valchion - Importance of a Name

Hey. So, I haven't been doing a HUGE amount of work on Soldier Of, but I'm slowly making progress on my main project here. I've also decided to change the name.

I've decided to change the name from Soldier Of to Valchion, as Soldier Of sounds generic, and doesn't really tell you what the game's about. You're not a soldier in the game, and you don't really war on the invading robots, but rather are just out to get to the center of the city to rescue your family. I think the new name helps to make the game unique.

I stopped development for a little bit (a couple of days) because of a game-crashing bug that occurred whenever I switched from the title screen scene to one of the game scenes, but I figured out what the issue was, fortunately. The bug's since been fixed, so development continues.

I remade the entire GUI with a Python module courtesy of Moguri from the BlenderArtists forums. The module's name is BGUI, and makes displaying GUI a lot easier and more precise. While it took a little while (a few days) I'm glad I re-made the GUI with it, for sure.

Most of what I've been doing is just trying to polish the gameplay, AI, graphics, etc. I'm not really adding new things, which can feel a bit discouraging, since the game's not getting any 'bigger'. However, the difference between the current state of the game and the last demo I've released should be pretty big, which is encouraging. Hopefully I'll get a new one out (that's cross-platform) in a matter of days.

Anyway, thanks for reading and watching my game Valchion develop!

By: Unknown On 11:30 AM

Continue Reading

3D Lighting and a New Item

Hey. So, progress continues on Soldier Of. Recently, I added 3D lighting, and a new item, the flashlight.
The reason that I updated the lighting is because I needed the flashlight beam to be able to go behind obstacles. Previously, lights were in front of all objects - now, they are fully three dimensional. Some of the lights were also flat planes before, but now they're all three-dimensional as well.

The solution to the problem that I went with lacked a bit of finesse. I ended up basically duplicating all solid objects and coloring them black for the lighting pass camera. It works well, though, and the Rasterizer doesn't seem to be complaining (too much).

Anyway, the flashlight should be a nice tool to help you navigate the darker maps. The further in you go, the darker maps will tend to get, as well, which makes it a very useful item to own. I might add an energy bar to it, so that you can't just walk around with it constantly. That might make it a chore to be underground, though, so maybe I'll just leave it the way it is. Here's a quick video showing the lighting system as it currently is.



I've been working on Soldier Of less than necessary recently as I've been working on other projects (non-game projects), like a new particle system for BGE games, and BlendSling (a launcher for BGE games). Both are coming along, and BlendSling's feeling really slick with the recent bugfixes that were committed to Blender. I'll probably try distributing Soldier Of with it, just to see how it works for everyone.

I'm planning to change the name from Soldier Of - it doesn't really describe the game well enough and sounds generic. It also has "Soldier" in the name, even though there is no soldiers in the game, hah. Anyway, I'll mull it over some more.

Anyway, thanks a lot for reading and watching. Have fun!

By: Unknown On 1:08 AM

Continue Reading

Soldier Of Progress Video #9 And An Actual Homepage

Hey. So, I've uploaded another video for Soldier Of, mainly just for the smooth FPS that MSI Afterburner's getting me. It's a great video recording program, and works really well when you've gotten used to it. I haven't worked on this much, as I've been working on a launcher for BGE games called BlendSling. It's working alright so far, and it should help to make distributing BGE games easier.



As a side-note, I've gotten myself a quasi-legitimate homepage. Hurrah! Check it out here. I'll also put a link in at the side. Anyway, thanks for watching and reading!

By: Unknown On 9:42 AM

Continue Reading

Misshoni Windows Pre-alpha Demo

Hey. So, here's the Windows pre-alpha demo for Misshoni. There's a readme included in the folder. Thanks a lot for reading and watching my progress through this month! I'll see about Linux and possibly Mac later on / tomorrow.

11-1-12 NOTE: The file was compressed with 7-Zip, and so is a .7z file. Please use 7-Zip or another .7z compatible file compressor to extract it. Here's the link. As far as I can tell, there's a problem playing the game on Intel / low-power graphics cards. If you play on a normal desktop card, it should play fine.

By: Unknown On 12:23 AM

Continue Reading

Misshoni Development Video

 Hey. So, here's a development video showing my progress - co-op partner AI, some basic fighting, and Drop-In, Drop-Out style support. The video's after the break below.

By: Unknown On 1:27 AM

Continue Reading

What Is Misshoni

Hey. So, it's been a couple of weeks since my last post, and in that time I've been working on my month-long co-op Metroidvania game, Misshoni. It probably won't sell for very much when I'm finished (I'm thinking $2-5). As usual, I'm using the Blender Game Engine for this project. It's been going well so far.

Misshoni will be a short co-op Metroidvania with emphasis on teamwork and getting by with help.

Fighting the first enemy, the Slice.

The idea for this is to make a short game that emphasizes co-operation just as much as the traditional exploration, combat, and puzzle-solving as Metroidvania titles. Surprisingly, I can't think of any Metroidvania titles that has co-operative gameplay, offline or online. It seems like it would be a good fit, which is why I'm attempting to tackle it with this project. I think it would be a nice thing to go exploring a world with your friend, and challenging the obstacles that arise.

Trying to do some sort of
wave-dash technique with
recoil. :p

Something that would not be so much fun would be if the game forced your characters to stick together, or forced a split-screen. Forcing your characters to stick together defeats the idea of individual exploration (i.e. each person going off to do something on their own). Forcing a split-screen takes a lot of the room to breathe and see what you're doing, even when you're right next to each other. I think the best solution would be conditional split-screening - namely, that when your characters are close together enough, you'll automatically share the screen, and when you're too far away, the screens split into their own 'windows'. That way, you can have individual exploration, while still having the ability to come together to tackle common goals. I don't know if I'll do enough to really take advantage of this functionality, but I think it could be fun.

While the end of the month is approaching rather quickly, I have gotten quite a bit done, including the basic player movement and gameplay, an enemy, the background and setting tiles, and some of the GUI. I also have a few sprites of the enemy at the left. I have a pretty good idea of what he'll do. Do you?

I still plan to have something finished by the end of the month, even if it's not completely finished (a demo, an alpha, whatever). Anywho, that's pretty much what I've got so far. Thanks a lot for reading!

By: Unknown On 10:30 AM

Continue Reading

Quick Co-Op Game and Soldier Of Progress

Hey. I can't believe it's been a whole month and then some since my last post here - I should keep this more up to date. So, I have been working on Soldier Of, but I've also been thinking about working on a different title.

But first, about Soldier Of. So far, I've done a lot of work implementing maps. They display points of interest, like enemies on the same map as you, items that need to be collected, and save points. They also can be rotated around, so that you can really check it out. Maps aren't 100% accurate, but they should provide a good amount of information to allow you to explore areas and watch out for traps.






Another thing I've done is add food. Rather than picking up hearts to heal you, you now pick up actual food. I think that's a better method, as it's a bit more logical.

Finally, I've been working on adding new enemies. One of those is the Shock Beetle, which slowly lumber toward you and are very, VERY strong. They currently take quite a bit to take down. When they touch you, they shock you and send you reeling back, making them difficult to deal with, especially on narrow ledges.

Another enemy I've added is the Vulture, which hovers above you and follows you around while firing slow-moving bullets at you. Its height and speed can be annoying, but keeping calm while fighting it will benefit you.






So anyway, I was thinking of taking a little break (about a month) to try working on something small - a co-op game. I think it would be fun, and I could see it selling alright for a few bucks. I should have more later on, when it's more developed. Have a flying bug enemy instead.

Alright, well, thanks for reading, and have fun!

By: Unknown On 11:41 PM

Continue Reading

Boost Bracelets and Game Optimizations

Hey. So, I'm still working on Soldier of, implementing some new items and working on the maps. The items I've added are the Spread Shot gun, and the Boost Bracelet. An animation showing it's effects can be seen after the break.

The Boost Bracelet allows you to run quickly, breaking through certain blast-resistant walls (the silver-blue ones pictured below), and smash into enemies. If they're weak and light enemies, they'll be KO'd with one hit and go flying. Otherwise, you'll bounce right off of them, having inflicted some damage. While running at critical speed, you're invulnerable to gunfire. The down-side is that it takes a little while to build up your speed to critical level - before this, you're completely vulnerable. Hitting anything solid will cause you to bounce off of it, as well.

 Using the Boost Bracelet, neither blast-resistant walls
nor light enemies can stand against you. 

Something I've noticed is that some of my earlier maps feel a little out of place and bare. I don't want to just scrap them, but I feel like the flow of the game feels more like a spider web, and less like paths that you can take in any order if you've got the correct items. So, I'm trying to work on blocking areas off that you can't reach with items, so that you don't get distracted from the main path you should be going on. At the same time, I want to make sure the world feels like a coherent, sensible city.

In addition to fixing little things and adding sounds, I've found a way to speed up the loading time of the game significantly (probably the way that I should've gone for writing the game in the first place). A quick test cut it from something like 4 to 5 seconds to around a half a second, or something like that. 4 - 5 seconds isn't a lot, but when the game reloads from a save point every time you die, it can get a little annoying.

 Basically, I currently have all of the maps in the game in a single scene, which means that the Blender Game Engine loads it all up and places all of the objects, unnecessarily for my game. In addition, all of the objects execute logic, even if they're not on the same map as the player. This slowdown is minimized by slowing the frequency of script execution and stopping scripts early for objects not on the same map as the player, but it's still happening. It would be far faster to split up the maps into individual scenes, or at least sections of the game world into their own scenes (i.e. all of the sewers in one scene, all of the city maps in another, all of the park in the third, etc). The definite upside is that the game wouldn't take nearly as long to load, and that the logic load should also be reduced. It's something to think about / implement, to be sure.

Anyway, that's basically what I've been working on so far. Thanks a lot for watching my space here and reading about my adventures in game development!

By: Unknown On 4:29 PM

Continue Reading

Devlog Video #8 - Graphics and Stealth

Hey. So, here's another development log video showing the new stealth mechanics and improved graphics in Soldier Of. You can check it below.

By: Unknown On 9:22 AM

Continue Reading

8-11-12 - Soldier Of a Bit of Progress

Hey. I've been making a lot of progress on Soldier Of recently. Better graphics, bug fixes, a new item implemented - the next demo should be really great!

I want to build up the maps in the game to be 'thicker'. I tried that in the screenshot to the left. Something I didn't like about the maps in Soldier Of was that they felt sparse, as though they weren't connected, or even individually important. I want to give the feeling of moving through a city, with lots of streets and alleyways, even if they can't be traversed, just to get rid of that empty feeling. I want it to have a lot of a 'secret' feeling, where you don't really know what could be around the next turn, or what will happen next. Hopefully I can get the level of detail on the maps that I want for the whole game. :S

I also fixed up the colors to be less eye-poking (in a bad way) and be more subdued, while still keeping a colorful palette. I've also added a filter that appears over the screen if you're outside to give more of an 'outside' feel. The unfiltered shot is to the left, while the filtered shot is above. The characters now have a colored outline, which (I think) makes them stand out compared to the more monotone background black-outlined objects, though the enemies get a little lost in the filter effect.

I've also stopped using the built-in light shading of Blender, and just have shadeless objects now, with pixelled shading effects. It's a more smooth, cool effect, in my opinion. I probably should have done it from the beginning.

I've also made a logo that should appear at the beginning of Soldier Of, and should appear at the beginning of my other games. I animated it with Blender (it can do so much)!  I didn't put a lot of thought into it, though, so maybe I'll need to really work on it to make it really shine.

An idea that I liked was that the logo would appear differently depending on which game it is. For example, for this, the logo might have a sneaking character, or a character holding something up, while the logo for a game like Dungens might be about placing blocks and performing acrobatics. It could use a little fine-tuning, but I like it a lot. :)

Anyway, it was a short update, but that's all for today. Thanks for reading! If you want to follow day-to-day progress, follow me on Twitter!

By: Unknown On 11:12 PM

Continue Reading

Would You Buy: Dungens

Hey. So, I thought I'd post about one of my older projects that I made in Game Maker awhile back. It was called Dungens, and it was going to be something like a user-creatable Metroidvania.

I made a video showcasing it and showing how far I got with it.


I was wondering if I could get some feedback on it - would you pay a few bucks for something like it?

By: Unknown On 1:12 PM

Continue Reading