Top  Previous  Next

Justin has created a great looking, old school, retro style, frantic action game. Read on to learn why this game is a little gem.


Q: What type of game is SWORDLORD and what makes it unique?

A: Swordlord is an arena fighting game that uses a simple sword singing mechanic, retro graphics and soundtrack. I'd like to say that the most unique aspect of the game is how you and the AI must swing your weapons to cause damage to each other. It can be a fun awkward mess, but can still feel like a real sword fight sometimes.


Q: Why did you choose Gamestudio for this project?

A: When I was much younger in high school, I chose Gamestudio because it had a "teach yourself programming in 7 days" type tutorial that really got me interested! Imagine me, a new artist being able to create the most epic game and artwork the world would ever see! I always knew I was going to be an artist, but to be able to learn the foundations of programming in that short amount of time was really awesome to me, so I bought the kit, came with a floppy disk and all, and went to town. Gamestudio's ease of use, very fun scripting language, and having ALL the tools I needed in one package was incredible. I want to emphasize that I had no coding or scripting knowledge before Gamestudio, so it was probably the best learning tool for programming I've ever had the motivation to learn. You learn very quickly when you are doing something you love.


Q: How big is your team and how much time did it take you to complete the game?

A: I made Swordlord by myself. It took around 3 months, but that's including work, life and other things outside of game development. I would have been able to finish it much faster. After the core game was made, I actually took another month after to do a little playtesting, as well as sit and bask in the idea that I have actually finished a game! I couldn't believe it.


Q: How are you generating those impressive particle effects?

A: Actually, a majority of the particle effects aren't using Gamestudio's native particle system! Many of the effects like debris, blood, pickups, explosions and etc are just animated entities that don't have a smooth filter on them to keep them crunchy and retro. However, I did use regular particles if I wanted to give things like a subtle shine or highlights, or leave a non-noisy trail like the final boss explosions.


Q: What is the most complex piece of code when you are creating a game like SL?

A: The most complex area of code would have to be the AI, not necessarily because the AI is very smart. In this game I chose to use the Gamestudio physics system, one physics object for the body, one physics object for the weapon and a third non-phys object as the body graphics, and constrain all these to each other. The player was relatively easy to make concerning tying the two phys objects together, and getting them to spin on player input, there is no decision or intelligence input code for the player. But for the AI, I needed to combine both the physics system and a rudimentary AI and get them working together. If the AI wanted to move to a certain point, no longer can I just c_move the entity over there, but now I had to apply a force, which meant the AI could overshoot its target. This was actually a good thing, they could miss you if they moved too fast.


The AI will move away from its target if it's too close, some AIs will only swing in one direction, others can swing in two directions, others swing more violently when they are low on health, and some change their swing styles randomly. Also, since the weapon was a separate entity than the main body, I had to get the weapon to communicate between the main AI and vice versa, so that each entity worked together as one unit. Because of the physics system working together with the AI system, I feel that every time you fight the same enemy, it feels different each time.


Q: How does the RPG component of the game work?

A: The RPG component is the most simplest rudimentary RPG system I've ever seen in a game! It's very simple: each weapon has an ID number, and each number has a series of hard coded stats on it. Swords are the lightest weapons in the game, axes are medium weight, and maces are the heaviest. Each weapon has weight, damage and cost. All I had to do was to change the player's "weapon_id" number when he purchases a new weapon. Once the player's weapon ID changes, the weapon itself changes and gains all the attributes of that weapon. Same with the armors, the player gains new hard coded stats like max HP, and gains a little weight too :)


I put the shop in the game because I wanted you to be able to see what you could purchase, and work your way to get it. When you kill an enemy, I wanted you to feel satisfied not only with their lifeless body and screams, but the shiny animated money that pops out so you can buy better gear!


Q: Why did you price the game at only one dollar?

A: I personally don't think the game is worth more than a dollar, it was a labor or love/fun and I don't want such a high barrier to play the game. There are a lot of better games out there, but that doesn't bother me. Any sales I make on the game will be used on small things like a new GPU or bigger things like charity.


Q: Please give us a few tips for the beginners out there.

A: Here is a small sad story first:


When I began understanding and doing my own code for Gamestudio, I started out making a game with a very huge scope. I started working on a 3rd person shooter. I actually still have the working prototype on my computer, which utilizes many systems on top of each other: 3D path finding with nodes (George's amazing AUM series), squad control, bone rotation that worked on top of animation, simple dynamic hair effects, a somewhat effortless cover system, grass effects, a body part collision system, a system where AI's could know which allies where around them and much more. I spent about 4 years working on this on and off, and I came to the realization that there is still no game that came out of it. So then I painfully put the game on the back burner and went smaller.


I started working on another 2d shoot 'em up with a tile system and level destruction. This was the game that I chose to be much smaller than the 3rd person shooter. I spent around two years making it. It actually has a very good amount of progress, and with some more time I could actually finish it. But once again, I found myself adding more things, and this time there was a story around it. It just kept getting bigger and bigger. Once again, I begrudgingly put it on the back burner and went ever smaller.


Finally, I thought of Swordlord. A single level with simple AI's running around, a wave system so that I didn't have to design new levels, and a simple swinging mechanic. I could say with confidence that when I began working on the preliminary prototype of Swordlord, I already saw the beginning and end of the game. I knew how to end it! This realization, the idea that I know how the game is going to end, and how short it would be, really helped me finish it.


Even though Swordlord isn't popular, and I'm not a really good game developer, here are some major tips I have for the beginners:


1. Make something small and finish it.

And that right there is really the ultimate take-away I can give to any beginner out there. Make something small and finish it. There is no requirement that the game should be perfect, or perfectly balanced, or have a perfect story or perfect graphics, or some mind blowing mechanic. Just make it small and finish it. Yes, we all want to make the next epic MMO or FPS, but you will never ever get there starting out doing big projects. Make a small game, polish it and only then do you even have a chance at being noticed.


2. Marketing

The second take-away I would really encourage all of you to actively take part of, especially as a solo or small team is marketing. Marketing and social media is so important for game developers its not even funny. If you spent 6 years making a cool system in your game, and no one knows about your game on release, then your game is on equal footing as a game that took 5 days to make... no one knows about either. So get on Twitter, tweet screenshots of your game (#gamedev), even if its in early stages. You need a community of people seeing your game. I'm saying this because even though one of my Twitter accounts has about 900 followers, only a very tiny percentage of those followers actually bought the game. Tweet your game, put it in bundles, comment on forums, make YouTube video updates, stream your game dev on twitch.tv, post on Tumblr, make a Facebook page, make a website, link all of these together. You need as many eyes as you can get.


3. Learn from each other

I'm a firm believer that there is not one human being on earth that has made themselves what they are on their lonesome. Everyone depends on each other, whether obvious or not. I've learned so much from George's AUM tutorials, that I still use them as references, even his old A5 and A6 tutorials. Post on forums and ask questions, answer other users questions. Play your favorite games, and see what they did right, and what you can do similarly.


4. Take Breaks

It can become a source of pride for us game dev geeks to tell each other about crunch time and heartaches and how niche our little world is. We revel in the idea that we are underdogs working against the clock and life, and spending weeks on some code drinking soda and eating pizza. But as I grew up, and realize I'm not young anymore, you need to take breaks. Whether that break is a week or a month doing something totally unrelated to game development, you need to take it. You will come back to your game with fresh eyes. Game development can't become work, it needs to stay fun, or else what's the point? Also, some of your best gaming ideas can come from when you are NOT gaming...


Thank you George and the 3DGS community.


Game Trailer:






Thank You, Justin!