Video: Second demo for my game

April 3, 2015 at 3:38 pm (Game Development, Games, Processing, Programming, Video games) (, , , , )


I’ve finally gotten around to making a video recording of my new game demo! Part of my problem was finding a suitable video capture software suite. I ended up using Open Broadcaster Software, and it turned out fine; I WAS using KRUT, but it had issues with the audio capture.

Anyway, while recording it I ended up finding out that half of my rooms didn’t make it into the demo! I had an issue where a locked door led straight to the boss level. That kind of sucked. Here’s the video though:

Advertisements

Permalink 1 Comment

Project: DarkWolf2D (2D Dungeon Crawler)

January 10, 2015 at 4:30 pm (Game Development, Games, Graphics, Java, Processing, Programming, Rant, Uncategorized, Video games) (, , , , , , , , )


Over the holidays, I had some time to upgrade the core code for my game engine. I’ve upgraded the version of Processing that I use as well, which means I can use shaders for rendering along with some of the nicer JSON loading features. While I have a “version 2” of my engine working though, I haven’t yet retro-fitted it into my Zombie Mansion yet. This is coming in the future, but for “proof” that my code works, I’ve been putting together a small game based on a design I had in a dream. It’s the “basic” version of the idea, which means no multiplayer and no nice graphics.

The idea is for a dungeon crawler action game that takes ideas from the MOBA genre. I know how it sounds, but it’s actually a very basic idea and it’s already half built. It’s a player-vs-environment game right now where the player begins at level 1 for each dungeon and has to level up as they progress to bosses. The theme for it is an alternate history WW2 where the characters are different classes such as “US Medic”, “Russian Sniper”, or “French Resistance Fighter”. Each class has a basic attack and a list of abilities they can level up and use. I’m keeping the XP system as simple as I can (although I’ve never built one before), and I’m not using any items for the game right now.

For rendering, it’s a 2D game with no character animations; just a static side-shot image. This should keep the dev cycle pretty low for now. I also have a feature backlog that I’m considering making public, but for now I’ll only do that if I have anyone comment that they actually care to look at it. It’s a list of all the features that I plan on implementing (some are basic things like “add audio to the game”, and it functions as my “todo” list. As I build in features, I mark them as “Complete” and they shuffle to the bottom of the list for storage.

Edit: Added a screenshot. It’s very basic and you can’t really see anything worthwhile. Just showing that I can at least render the player in a level. I’ll make a video later.

First screenshot of DarkWolf2D

First screenshot of DarkWolf2D

 

Permalink Leave a Comment

Aftermath of Zombie Mansion Alpha 1 Build

July 18, 2014 at 12:40 pm (Game Development, Games, Graphics, Java, JavaScript, Processing, Programming, Video games) (, , , , , , )


So at this point in time I’ve had multiple people play through my game demo. The results were actually better than I thought. I think only one person wasn’t able to run it (still not entire sure why, but that’s future Jake’s problem now). There were a couple major issues, but those were found and fixed as well. One of the bugs was that I didn’t include the assets for the 3D objects, so when the players entered the room with columns, the game crashed. There was also some scripting errors driven by not having necessary images wrapped up in the resources archive. Logging definitely helped out there.

The last major issue is unsolved, but lies with some code I threw together for the level selection screen. I think some of the click events aren’t going through, or it’s not loading the levels properly. I think this may have something to do with that particular tester running the game through a zip file though. I was shocked to find out that it worked period though.

I got some pretty decent feedback from one tester in particular though. He gave not only bug reports, etc, but opinions on controls, aesthetics, and game flow as well. Most of those things were explained away as “placeholder” stuff, but still; it was useful information to know what a tester/player is thinking when they see that stuff. When I show most people my game, I need comments like “looks neat and retro” or “I like the camera spin feature”, but not enough people pay attention to tiny details.

Anyway, that’s the update. I haven’t had free time to cut a second build or to work on new levels or anything.

Permalink 2 Comments

[Video] Demo Play-through Part 2

May 20, 2014 at 4:50 pm (Game Development, Games, Java, Processing, Programming, Video games) (, , , , )


Here’s part 2 of the video. My video converter wouldn’t let me have it all in one go (and thus I am on the market for a new converter program now). I’ve gone back to edit part 1 to have a link to this video as well.

Permalink Leave a Comment

[Video] Demo Video of Zombie Mansion

May 19, 2014 at 6:14 pm (Computer Science, Game Development, Games, Java, Processing, Programming, Video games) (, , , , , , , , )


Here is part 1 of a  5-minute video of a short level I put together in a playable demo. I play through the puzzles and traps of the level and show off some of the details and mechanics of the game. Please forgive the large amount of placeholder art and the rough nature of the game so far.

EDIT: Part 2 coming soon

Permalink 1 Comment

[Video] Combat demo video

April 23, 2014 at 6:40 pm (Game Development, Games, Java, Processing, Programming, Video games) (, , , , )


Here is a short video showing off some combat mechanics and example animations. The zombies will stalk the player and attack with a melee animation. I’ve included sound in this video as well, although there’s no music in this clip.

 

Permalink 1 Comment

[Video] Navigation in Zombie Mansion

April 17, 2014 at 7:31 pm (Game Development, Games, Java, Processing, Programming, Video games) (, , , , , )


I’ve done up some more rooms and made another demo video! This one shows how navigation will work in the game. Right now the camera is still orthographic due to some control scheme issues, but I assure you, isometric/diagonal walls looks pretty sweet as well.

Permalink Leave a Comment

Video of my game!

April 15, 2014 at 4:48 pm (Computer Science, Game Development, Games, Java, Processing, Programming, Video games) (, , )


I’ve finally taken a short video of some of the mechanics in my game! I’ve posted it on the YouTubes for both of you to see it. The video looks pretty blurry right now so I might have to re-post it or mess around with it later. It’s my first time posting a video, so it might take some effort.

Permalink Leave a Comment

Quick and Accessible Inversion of Control

March 14, 2014 at 1:37 pm (Computer Science, Games, Graphics, Java, Processing, Programming, Rant, Teaching, Video games) (, , , , , )


So by now you’ve probably at least heard of the magical beast known as “Inversion of Control”. You may even understand what it is. If you’re in this boat, why aren’t you using it more often?? (if you are, you can read the rest of this article with your head held high).

There are tons of places on the interwebs where you can learn all about Inversion of Control (or IOC), so it doesn’t make sense to write up a detail explanation and then have people correct me on it. The short version of it is that it lets you defer your problems to someone else (future you for example). You allow the implementation to be abstracted in such a way that you can conveniently inject it in such a way that would make your college programming professor proud and/or confused.

For this example, I am going to use PicoContainer and Processing. PicoContainer is an IoC library for Java, although you could implement what it provides yourself through a variety of techniques I won’t tell you about here. The idea is just to show you a brief intro to what it can look like. In my example, I have a Graph object. It is the “M” of our MVC, and we want to separate the “V” from it. This means that the bit of code that draws the graph on the screen is going to be extracted. The kicker is that the way we abstract it will allow us to re-skin the graph in whatever way we want, whenever we want. We just inject a new view without changing the model layer and we’re good to go.

/**
  This is our interface for abstracting the View from the model
*/
public interface GraphView {
  public void draw(PGraphics g, Graph graph); 
}

/**
  This is our Model: The object we want to abstract the view from.
*/
public class Graph {
  private MutablePicoContainer graphConfig = null;

  public Graph() {
     graphConfig = new DefaultPicoContainer();
  }

  public MutablePicoContainer getGraphConfig() {
      return graphConfig; 
  }

  public void draw(PGraphics g) {
     // I'd recommend caching the view ahead of time to remove overhead
     GraphView graphView = (GraphView)graphConfig.getComponent(GraphView.class);
     graphView.draw(g, this);
  }
}

Now here is the part that makes it all work. I’ve written this in Processing code, but it is essentially simplified Java anyway. In this snippet of code (although it is a working program if you include the previous snippets), I instantiate our Graph object and then inject a View. In this example I’m just showing the power of IoC by including an anonymous implementation of a View object. In the “real world”, you would have written it as a standard Java object.

import org.picocontainer.*;

Graph graph = null;
void setup() {
  graph = new Graph();
  graph.getGraphConfig().addComponent(new GraphView(){
      public void draw(PGraphics g, Graph graph) {
        g.pushStyle();
        g.stroke(200);
        g.noFill();
        g.ellipse(25, 25, 10, 10);
        g.popStyle();
    }    
  });  
}
void draw() {
  background(0);
  graph.draw(g);
}

Now to summarize, we have accomplished our goal of abstracting the view of the graph from the data represented by the graph object itself. This means that we could completely re-skin the visual representation of our graph without touching any of our previously written code. If we wanted to draw the draw in 3D, we could just inject a new implementation. If we want it to be rendered using only ASCII characters, we got this. In the case that you still don’t see the value of this, consider a game you’re probably writing right now in your spare time:

You have a general “GameCharacter” class that both the PlayerCharacter and AiCharacter classes inherit from (Because you’re object-savy and generally good-looking). Both of these allow you to draw the characters differently. What happens when you decide to add new AiCharacters that act exactly the same, but look different? Well, you could throw in an IF statement and just check a state variable…. OR you could abstract the view, just like in our example! When you construct the AiCharacter objects, you inject a View object that will do all the drawing. As an object-oriented purist, you feel content, and as a game developer you feel pleased that you were able to trim off an “IF” statement from your render loop. You high five yourself.

Permalink Leave a Comment

Automated testing in game coding

March 10, 2014 at 9:38 am (Computer Science, Games, Programming, Rant, Video games) (, , , , , )


So my musings so far today have circled around the idea of automated testing in game engines. Automated tests are a series of unit or integration tests that can automagically verify whether or not you broke your code.Here is a quick explanation of both types of automated tests:

Unit tests are tests that isolate specific areas of your code and rigorously test individual parts. They typically pretend that the rest of your code doesn’t exist (usually accomplished via Mocking frameworks) and when you think about it, isn’t that how you’d debug a problem anyway? An example would be “Does this function in the class return the values I’m expecting when I give it input?”

Integration tests on the other hand function to test your code “as it is” for lack of a better phrase. It tests how the classes and modules of your code work together and whether or not your “business logic” is correct. An example would be “When 3 players connect to the server, does the database correctly log their actions?”.

Now, in game coding the typical idea is to get the game done ASAP and cut corners wherever possible since time is money. By this, I don’t just mean what big companies such as EA, etc. do to pump out new games every five minutes. It functions for all game development to a degree; if your game takes 10 years to be built, you’re probably going to have an out of date game and you’ll have to re-code at least some of it.

Do automated tests truly add value though? If you are a one-man shop, your argument is probably that you know the code intimately and that you stick to your coding guidelines (Thanks to Ruben for the argument). What happens though if you need to modify a really complicated system 6 months after writing it (while not forsaking the codebase in your day job)? Is booting up the game 40 times to do trial and error worth it more than a 30 second run of your automated test suite?

It most likely depends on your perceived usefulness of the tests. If you are just writing unit tests to verify that setPosition(1,1) actually sets your X and Y positions, then there probably isn’t any advantage. You’re likely to waste time building up a nice collection of tests to verify what you know. If however, you are concerned that your A* algorithm is a bit fragile and you’re worried that the AI would try to do something questionable on the game board, perhaps it might be a good idea while you’re working on the code to have some tests.

Keep in mind though, that the idea is to be able to verify without a doubt that the pieces of your code work 100%. If you don’t write your tests correctly or if you don’t even run them, then you’re only fooling yourself. Perhaps you have a good reason for fooling yourself though; perhaps at parties you impress people by telling them you have automated tests in your game engine code…

 

 

Permalink 2 Comments

Next page »