next »

[brock555]

Hi

This is the start of a devlog for Little Hitler. We’ve been wanting to make this game for a very long time and in early 2013 we were finally in a position to start working on it. We would love to get as much feedback and support as the community is willing share, so thank you in advance.


Overview

Little Hitler is a traditional Beat ‘em up fused with the endless replayability of a Roguelike.


Story

A group of radical, Hitler-fanatic scientists have recovered a hair from Hitler’s mustache, and are attempting to clone him back into the world. So far the enemy has only managed to create miniature versions of him, but they are getting dangerously close! Your mission is to infiltrate the scientists’ secret laboratory and stop their evil plot!


Platforms

Because its a Beat ‘em up, a controller is by far the best experience, so we’re concentrating on platforms that support gamepads. For sure we will be able to ship the game for PC, Mac, Linux, and Ouya. We hope, and will do everything we can, to be on Steam and next-gen consoles as well.


Mechanics

As mentioned in the overview, our game is a Beat ‘em up blended with Roguelike elements. So at first glance it will look and play pretty much like a traditional old school Beat ‘em up, but on repeated plays more and more Roguelike elements will surface. Here are a few of the features we are planning to include:

• Permadeath
• Random environment generation
• Randomized level generation (length, layout, enemies, bosses, drops, etc)
• Resource management/inventory system
• Local Co-op Multiplayer

Technology

We are developing this game using Loom. We chose this SDK because we wanted to make a 2D game that supports gamepads and can publish for Windows, Mac, Linux, Ouya, and mobile. The game is written in Loomscript, which is a blend of AS3 and C#. They have this awesome live reload feature which saves so much time. If you haven’t heard of Loom check it out, because we are loving it.


Concept Art

[icompose]

This seems like it could be fun.  Would you need a soundtrack?

[brock555]

This seems like it could be fun.  Would you need a soundtrack?

We would love to hear some of your samples.

[icompose]

This seems like it could be fun.  Would you need a soundtrack?

We would love to hear some of your samples.

www.soundcloud.com/skyler-moosman
http://www.youtube.com/channel/UC_FOjw2T-Xrt5h-ctk31iFg

I don't have a ton up right now, I am going to upload a chiptuney/dance song i made earlier this week.

[brock555]

Weekly Update #1

When you’re cruising down the street in your six-fo’ you have to be constantly scanning your surroundings or you may find yourself on a bumpy road filled with regret. As Jonathan Blow always says, “If its true in the ghetto, its true in game development“. ** In an effort to avoid regret and tears later in the development of our game, half of my week was spent refactoring code.

A wise man, once taught me an important lesson. “All we can do is to try to make the best decisions we can with the information we have available”. You don’t want to spend your life looking at the past wishing you made a different decisions. In the course of development, as in life, you are constantly learning. But at the very same time as you’re getting smarter, the world continues to change. Ideas are evolving, requirements changing, and assumptions failing. Little Hitler has been a constant learning process. We originally thought we were going to develop it in Air, but then Loom busted on to the scene and it quickly became apparent to be the much better choice. With the switch to Loom came a learning curve in the form of new apis and a componentized architecture. As with any SDK you have learn and adapt to the way the framework designers imagine you would develop to get the most of their framework. So after months of development and constant learning, it became clear that some refactoring in our underlying classes was going to be required.

After three or four focused days of development, we came out the other side with greatly streamlined and condensed package structure as well as a base Spatial component. It was definitely worth the effort for me because the changes allowed Bucketz to implement ramps in a very short amount of time and set us on a clear path for the future.

** The Jonathan Blow quote is totally fake and completely absurd. It was inserted into the post for entertainment purposes only. He is a ridiculously intelligent and talented developer and you should purchase all his games because they are great. No Jonathan Blows were harmed in the writing of this blog post.

[gokimen]

I always love a hitler in a game! LOL
Waiting a gameplay footage or playable version 

[brock555]

I always love a hitler in a game! LOL
Waiting a gameplay footage or playable version 

We'll try and post some footage soon. We're trying to get a rough background in first.

[brock555]

Hey Everyone,

We are starting to rough in a background art. Here is a quick pick for the Black Forest. We plan on having randomized times of day, so this a twilight test seeing how the colors work with our characters etc.

[brock555]

Here is the same background with more details filled in. I think this is the level of detail we're going to shoot for.

[brock555]

Weekly Update #2


Hello Fellow Indie Devs



I recently purchased a copy of Programming AI by Example because I wanted to turn our little enemies into lean mean killing machines. I know that the genre dictates that enemies be somewhat stupid and weak, but I don't want them to be boring and completely predictable. I picked up Mat Buckland's book based on some recommendations by fellow devs and let me just say WOW. I'm only three chapters in, but I can easily recommend this book to any aspiring game developer. What I've learned in the first few chapters easily covers the cost of the book.

The book was originally purchased with the intention of improving our enemy AI, but I've actually gotten a lot more than just AI know how from it. For instance the second chapter talks about finite state machines. These lay the base for the AI that he builds upon through out the book, which is great, but they just happen to be the building block for pretty much every object in our game. Based on his recommendations and examples, I spent the last two days reworking our state machines to make them much more flexible and refined. One thing that was super helpful to me was learning the difference between a transition and a state, which allowed Bucketz and me to boil down or fighter states to nine states.

Turns out that Mat is so generous that he has posted the entire chapter on state machines on his website. If you like what you read, I would encourage you to purchase the whole book. Well, you've got some reading to do, so I guess I'll go back to programming.

[brock555]

Quick pic for ScreenshotSaturday - roughing in more level segments in Illustrator.

[brock555]

Weekly Update #3

The process of developing games, generally speaking, is a long one. Looking back on past projects, I can see that at certain times I've been so preoccupied with shipping games that the process of creating them stopped being enjoyable. For as long as I can remember I've wanted to make games. To find myself, at this time in my life, with the opportunities and abilities to actually be able to make games is a huge blessing and to not enjoy the actual process of making games would be a huge waste. I've been mindful of this flaw for a while and have been making conscious efforts in my life and with this game to lower my gaze from the distant horizon, focus on the present, and enjoy what is before me. With that in mind, I can say this has truly been an enjoyable week working on Little Hitler.

So what have we been up to? Well, since last post I have continued my work on enemy AI. Because a brawler isn't very much fun if the enemies are merely stationary punching bags, I've spent a majority of the week learning about and implementing steering behaviors. As I mentioned in the last post, this is the first time I've had to program AI and that is also the case with steering behaviors. Practically, this translates into a lot of brushing up on math that I haven't done since high school — vectors, intersecting lines, etc. Thankfully, the end results are enemies that can pursue the player or runaway from the player while avoiding obstacles. Here is a screenshot of a Hitler clone avoiding a rectangle obstacle.....check out those feelers! Creepy.





On the art side, Swag continued working on background art tests. This time seeing what an indoor level might look like. You can see one of the tests below,  showing an atmospheric laboratory bathed in the warm glow of evil.

[karlozalb]

The design is really cool, it reminds me (a little) Castle Crashers, but just a "touch"

[brock555]

The design is really cool, it reminds me (a little) Castle Crashers, but just a "touch"

Thanks. Thats a big compliment we love that game.

[brock555]

Sorry internets, its been a while bit since our last post because we have been
fighting with a dragon. In the AS3 world there is a fantastic library called
Dragon Bones. What is Dragon Bones?
It has been billed as the open source 2D skeleton animation solution for
Flash. The problem Dragon Bones solves is that character animations take up a
lot of texture space, so instead of having giant sprite sheets for sequence
frame based animation, the skeleton animation can help you save lots of
resources and memory consumption. Here is a quick intro video the Dragon Bones
team put together.

http://www.youtube.com/watch?v=1HiC2QDbyK0

Now there are a lot of great tools that solve the same problem as Dragon
Bones, some of the more well known solutions include Spriter, Spine, and Animo Spriteloq.
The BIG problem we ran into while searching for a solution for our game is that
currently NONE of the products support Loom SDK. Our only option was to port
one of the products over to LoomScript. Spine and Dragon Bones both have AS3
version, which by far is the path of least resistance, considering LoomScript
is so similar to AS3.  Ultimately, we selected Dragon Bones because of its
workflow. Our team has years of experience animating in Flash and Dragon Bones
allows you to remain in Flash to setup your skeletons and export animation
data and sprite sheets once your key frames are set. In the long run, that
workflow will be the most efficient for our team since it takes advantage of
our experience and speed using Flash and has almost zero learning curve.

As I mentioned before, LoomScript is very similar to AS3, however, LoomScript
IS NOT ActionScript 3 no matter how much it resembles it. We discovered this
the hard way through hours and hours of debugging. Honestly, its painful to
think back on considering all the time spend scratching our heads and banging
them against our desks. We discovered several small, hidden differences
between LoomScript and AS3 that people should be aware of. The most notable
one is that the 'int' class truly isn't an integer and doesn't  yield the same
results as AS3. Details can be found here. There also seems
to be issues with matrixes and pivot points being wiped out. Ultimately these
differences aren't a big deal to correct in code, but they turned into a big
deal for us since these differences were not documented anywhere.

Porting Dragon Bones ended up being a bumpy but necessary detour along the
road of Little Hitler's development. We've made it back to the main road and
we're excited to start making up some lost time. But, before I head out, I
wanted to share this....

We are very happy to announce and share with you a working version of
Dragon Bones for LoomScript.
Being able to say that has made the last week and a half worth it.