[Post Mortem]: Copulus – the love making, weight lifting god game

copulus_logo

Copulus is a 2D God Game in which you have to help your subjects populate their little world. In order to achieve this you need to balance their need for social interaction (and copulation) with the need to survive. I decided to try and stream line the “god game” mechanics and let the player focus on only a few tasks, as opposed to regular god games where you have to manage many different needs (housing, hunger, peril, happiness, loyalty, security, etc). In order for your population to survive and expand you only need to make sure they are feed, safe and can interact with each other. I even took this approach a bit further and merged survival/peril with hunger satisfaction. Before I go into the, regular, What went Right, What went Wrong topic I would like to present my approach for this entry:

Limitations breed creativity

Before the theme was announced I already established how far I can stretch things. I know from previous experiences how hard it is to stay on track of the initial design and how many features end up being thrown away in order to finish “something” before the time runs out. So for this edition of Ludumdare, I’d like to say I came prepared. Here are my, self-imposed, limitations:

  • 256×384 resolution (upscaled to 512×768)
  • must involve some kind of an AI
  • must be tile based.

Three rules in total. Three rules that, once the theme was announced, helped me establish a clear goal. For example, the small resolution and tile-based approach helped me establish the art style, level and user interface design. Working on a 256×384 screen I could only fit 8 / 12 tiles (32×32) on the screen, or 16/24 tiles at 16×16 pixels each. The AI requirement weighted in favor of the strategy genre and, it’s subclass, the god game genre.

From here on, I went with the entire map being confined to a single screen (in order to have a good view of your population, and not have to hunt for them everywhere). This also affected my User Interface Design and Experience, since It had to take as little screen space as possible. Little screen space for UI implied having only a handful of buttons during game play which, combined with the god-game thematic, had me limit what tasks the player could focus on. A small amount of tasks for the player to perform required me to streamline the entire “god game” approach and make it as minimalistic as possible (the soul experience as I like to refer to it). You can see how things developed further on.

training_gif

What went right

  • Using a WIKI to plan ahead. Features, classes, how the AI should perform, etc [click here for a screenshot of the wiki].
  • Not stretching further than I can and imposing strict limits.
  • Making fake-screenshots(mockups) before beginning development so I can plan my interaction approach.
  • Using tools and frameworks that I was familiar with.
  • Selecting a limited color palette to work with.
  • The UI only interaction means that I can also port the game to tablets.
  • Using “procedural” generation to save time (from level design) and focus on other areas.
  • Nailed the risk-reward motif due to Wolves acting as a source of food but also damage to the units.

What went wrong

  • My innate lack of knowledge when it comes to composing and/or generating appropriate sound effects.
  • Having to remove the “convergence” scene. After winning a level, the player was supposed to reach a new world with his highest level followers and watch them fight off the inhabitants. I regret removing because it would have had a better tie in with this jam’s theme. Further more, I had a system which allowed the player to revisit worlds that have been previously populated, to see how they are doing.
  • The game’s balance is a bit off. Level progression of your followers vs level progression of the wolves is tipped in favor of your followers for the first few levels. A few wolf summons in and you can only take them on if you have a high level character that survived.
  • Social interactions are only represented by heart animations on individuals, but it’s hard to tell who “copulated” with whom. More so, a death of a birth of an individual is represented by their respective sprite disappearing from the game.
  • Health, hunger and level indicators are way to small and crammed into a unit’s sprite.
  • The tutorial is just a image and does not convey all the information needed.

blood_gore

Conclusion

I feel that with each Ludumdare event I partake in I can quantify my progress as a Designer. My first entry required the player to quit the game in order to restart the level and featured only mechanics but no clear goal (also no Ui of any kind). In my last LD (7DRTS) attempt I finally had a entry with no missing UI options and a clear navigation path. You can see where I’m going with this. But all in all, I’m glad that with each submission I end up acquiring new knowledge. As far as limitations go I believe that it’s better to know what you should not do as opposed to not knowing what to do. Hopefully my next LD submission will blow this one out of the water.

You can play and rate the game here. Linux, Mac and, hopefully, Android coming tonight. I’ve also uploaded it to itch.io and, in the weekend, will release a post-compo version that has sound and the features that were cut off.

About these ads

Alpha 2 Technical Status Report #1

commanders

I know most of you want to see the latest juicy pixelicious art that Thomas has been doing for the game but guess what? This is a technical report (the first in a series of status reports) and none of that will be featured here! Instead let’s talk on where the game is at this point, what can you do with it and more importantly, what can it do for you? Let’s get right on that shall we:

Changelog:

Additions

  • Commanders-type units have been added in the game
  • Early keyboard-only support for playing the game
  • Improved modding support
  • Unit creation and editing has not been externalized from the code
  • New healthbars for the units to represent exactly how much life they have
  • Added scrollbars and tousch scrolling for some UI elements (buy menu, victory screen)

Removed content:

  • Unit abilities has been removed from the game

Fixes:

  • Random map scroll at the start of the match happens no more
  • Game starts in either fullscreen or window mode, based on the option ticked in the options menu
  • Icons and Effects now position themselves correctly when zoomed in
  • Player can no longer interact with the map/units/buildings during the AI’s turn
  • Exiting the game to the editor now brings back the latest map you were editing
  • OK/Cancel/Save now work in the editor
  • Going from scrolling to Colision+/- now works as intended
  • Fixed startup crash on Linux due to missing 64b binary

Now to go into detail about the changes and additions (I believe fixes are self explanatory).


 

commanding_unitsFirst thing I’ll be covering is the addition of commanders as playable units.

Up till this point commanders (or, as Thomas likes to call ‘em, GangBosses) were used only as “profiles” for the player, affecting how much damage a unit will receive/inflict or how much income is generated each turn. From this point on commanders will take a much bigger role in the battle as actual playable units present on the battlefield. At any point in time during a battle a player will only be able to have only one commander present. A commander boosts the stat of his units (albeit less then in the previous version) and has access to abilities. Once killed the stat boosts will be removed. The list of abilities that a commander has access to has not be defined yet but I can give some examples such as:

  • Attacking twice during one turn
  • Doing Area of Effect damage
  • Healing friendly units
  • Capturing building/houses (like scouts)
  • Sacrificing a friendly unit for a damage boost
  • Sacrifice it’s own HP to boost movement / attack for friendly units in range

 

Unit creation and editing has not been externalized from the code.

In alpha 1 if anyone planned to add new units to the game or change their settings they would have had to dive in the code and make changes to: unit_type.lua, buy_menu.lua and leditor.lua. From this point on units are loaded from external CSV files: mutants.csv and robots.csv. they look something like this:

csv_imgIn the said file you can define their stats, their image, abilities, if they can capture buildings, how much they cost, their animation states, their graphics/icons for the buy menu and sound files. Adding a new unit into the game is as simple as adding another entry in the file (example: Joe, Allen, ZapaTard, Crystal, ISN). I believe that this opens up new possibilities for modders and/or people who plan on using the game’s source for their own TBS game (more on this on the end of the post).


Improved modding support.

In the game’s root directory there is a game called MODS. In there you can place your own folder (example: “Advance Wars”). If you copy the contents of the Game folder into your own folder you can start modding the game. Files present in yourModFolder take precedent over files in /Game (if your mod is enabled). What this means is that now you can change the game and distribute your changes without altering the main game. Now, by default when starting the game it will run the native version. To enable a mod you need to edit game.lua and add the mod name on line 3 for the variable Game.modInUse = “yourModNameHere”. If the varaible is set to nil then no mods will be ran. In the future I plan on releasing a launcher for the game which will allow you to select what mods you want to use (amongst settings and other useful options). For those interested in how this is handled code-wise things are pretty simple. All the lua files I want to use are added to a table called includeList. I loop over that table and check to see if any of those files are present in the current enabled mod. If they aren’t the game defaults to those in the /Game folder. Here’s the code:

for i,v in ipairs(includeList) do

    local prePath = “mods.”..Game.modInUse..”.”

    if isModuleAvailable(“”..prePath..””..v..””) == false then
        prePath = “Game.”
       require(“Game.”..v..””)
    else
        require(“”..prePath..””..v..””)    
    end

end


 

New healthbars for the units to represent exactly how much life they have.

In alpha 1 we’ve received complaints regarding the healtbars. Players found that they couldn’t really tell how much health a unit has and how much damage he will take in a battle. Our solution to this problem is this:

healthbars_unitsEach dot on the healthbar represents one point of health. No more dots = 0 health = unit is dead. No more calculations, no more approximations. When you select a unit you will be able to see how much damage it will inflict to units that can be attacked in his range. Can you unit destroy the enemy? The healthbar will reflect that and will display no more dots. Hope this solves some headache’s and makes things go smoothly.


Early keyboard-only support for playing the game

By keyboard support I mean playing the game without the aid of a mouse/touch screen. A cursor/pointer is used to interact with the objects/units and it can be moved using WASD/Arrow Keys. Pressing space selects the unit/building underneath it and/or confirms movements or attack. This can also allow for the addition of gamepad support in the future. Now I say early keyboard support because things are not so peachy. The main problem with it falls down on UI navigation. In order to setup the user interface I’m using MOAIGUI a library for lua and MOAI that handles the creation of windows and ui elements (textboxes, buttons, images, etc), a library that was designed with mouse/finger input in mind. What I’m doing in order to use it via keyboard is to access the ui elements position via code and move a “virtual mouse” over them, basically emulating mouse countrol on the ui. It’s barely functional at this point and currently requires me to setup each window independently. The code is a tad messy but I’m working on it. Hopefully it will be ready in time for the next alpha release.


 

That’s it with the most important changes added into the game. Next I’ll want to cover some other game-related subjects. First of all we’re aiming to release alpha 2 in June (aiming for early June but you know how things go… might even be July). Now the next alpha will feature new Maps (older ones will be available for download separately) and 4 playable commanders (as units) and early campaign support.

Next we’re working on setting up a development blog to keep you up to date. Due to personal issues on my side ( mother has cancer and I’ve been on the road a lot because of that) development has gone a tad slow and many have wondered what’s happening with the game. By setting up a dev blog both me and Thomas can offer more transparency on how development progresses. Expect status reports (such as this one), technical stuff (implementing the AI and other fun things ^_^) and, of course, lots of screenshots and ART assets from Thomas Noppers. With a bit of luck we could even get (here I mean strong-arm) Grace to showoff some cool sound stuff. Blog should go up sometime this week.

osi_licenseThird thing I’d like to cover is the source code for the game. Up till this point I licensed it as free for non-commercial use, meaning that you are free to use the code for personal projects as long as you get no revenue out of it. Well I’ve been thinking about this and would like to change things. As of the next commit on Github I’ll be changing the license to MIT. What this means is that you are free to fork the code, change it, distribute it for free and commercial purposes. Just don’t distribute the code with any of the assets from the game (sound files or graphical images). With the way recent changes to the game are going I’m getting close to having Mutant Gangland’s code work as a engine for TBS games. I’m pretty sure that a few months down the road game-orientated contents will be truly separated from the actual code and will be usable to create other different turn based strategy games.

The game’s source is available on github. I recently setup a new branch “development”. Hoping to push updates every week, starting now, into the “development branch” while master will contain stable releases. Currently both branches are a mess. The most stable version should be this one. I’m a git newbie and I overlooked some stuff, but things will get cleaned up. In the meanwhile feel free to fork the source and/or submit issues. I’d love to see my repro getting some activity.

And that’s it for now. Keep an eye out on our twitter (@Zapakitul, @Thomas Noppers, @Mutant Gangland) or this blog for information when the blog goes up. And if you would like to buy the game you can do so here. Plan on using the code for your openAdvanceWars project or TBS-GOTY-2014? Drop me a line, I would love to help out. Also remember there’s a subreddit for the game available. Or you know what? Drop us a love letter at info [at] mutantgangland [dot] com.

 

 

Road to alpha 2 and streaming

mgl_commander

Hi everyone, a quick update to keep everyone on track with development. Recently I started streaming my side of development on Mutant Gangland via twitch. The reason I’m doing this is simple:

  • Early access buyers get to see how things are going in-between releases
  • New people could follow development and decide whether they want to get in on the action

I’ve released a new website regarding my streams. In the future I hope to release articles and document the streams (as in, what happened during X stream, where I implemented what) hoping it might be useful to others.

As for development updates, here’s were we stand:

  • Commanders have been coded in the game. From now on, they will not act just as profiles with strengths and bonuses but as playable characters (and main characters during the campaign).
  • Mods are in. Now in order to mod/change the game the players can place their mod files inside a /Mods folder. For example you can create a media folder and place the image you want to use for the Tank, or change the way the AI works. Later on I plan on creating a launcher from where you can select what mod to use.
  • I moved my main development environment to Linux in order to better support linux users. Previously I was mainly developing the game on Windows but problems with the Linux version have risen. Since the game’s logic is in lua working on the main mechanics will not be affected. The Windows host works pretty well I decided that I can take some time to get the Linux version working nicely, and what better way to do this then actually working in that environment. I’ve also rolled a new SDL host (based on the one made available by the guys from Stirfire studios) so this should solve some other issues people have been having with the Glut host. For alpha 2, the SDL host could be an optional download and starting with alpha 3 it will replace the standard one.
  • Keyboard support for the game has been added. Some minor issues with navigating through the menus only with the keyboard, but I’m working on fixing this. As soon as that passes I’ll add support for gamepads in order for people to play the game connected to their tv.
  • Halfnelson (MOAI user and developer) released a wonderful tool that allows me to build a web (HTML5) host for the game. I plan on using it to during streams, so people can play the latest build, and maybe during FeedbackFriday on reddit.

Thomas has been present both at GDC and at Rezzed this month showcasing Mutant Gangland and Penarium (a wonderful little platformer made with the guys from Self Made Miracle). You can read his thoughts on how GDC went over on his blog. For now, this is were we stand. I’m announcing every stream on twitter but you can also follow me on twitch and get notifications on what time it goes live.

Coding with the aid of MOAI and what it means to me

Moai_Logo_On_White_700px

Before I get into depths with the article/post itself I would like to make one thing clear: I am a bad, bad, BAD programmer. Most of the stuff that I implement is based on many iterations and hacks that, in the end, somehow get tied together nicely and function (almost) properly.

In my last article I stated that I started out making games back in 06-07 on the TGC forums, using DarkBasic and later with DarkGDK. This statement is important to this topic mostly due to the fact that I “grew up” with a code editor in front of my nose and not a visual tool, fact that influenced my decision to use MOAI. Back in the early days, DarkBasic was the closest thing to magic that I ever encountered. With just a few lines of code I could get a “game” up in minutes (and by game I mean interactive thingy with cubes moving ’round) and share it with everyone who had eyes to see my “masterpiece” (which I did, having posted 3 projects on the WIP section in 2 months). It had literary no visual tool there to help you with anything and I never bothered (nor had the knowledge) to make one myself. And I liked it, made me feel more in control. Later on I moved to DarkGDK which was the C++ flavor of DarkBasic, in order to learn the language “most-used in the industry back then”. Again, same thing, visual studio was my one and only tool. Now, 8 years later I still feel most at home in an environment that places a textbox with syntax highlighting in front of me.

I tried using using Unity 3D (even acquired a license at one point) only to get scared by interface not 10 minutes after first opening it up. It reminded me of Blender’s UI and I wanted nothing to do with it. With DarkGDK reaching it’s limits (and mine) in terms what I could do with it without something going hay-wire unexpectedly and crashing the whole damn thing I was in search of another framework to use. As stated, I’m a bad coder and writing my own from the ground up would mean loosing allot of time and ending up with a square for a wheel. I searched for a framework that would be high-level enough for me to string together a prototype in little time while also giving me access under the hood. And this where MOAI hits the nail on the head. Continue reading

Looking back on 2013 and plans for 2014

So I’m officially 1 year in as a wanna-be Indie Developer (since I have yet to release my game). It’s a tough ride governed by many decisions and mistakes. I’d like to take the time and share my experience after this first year. Hopefully it will be useful for people starting out or a good read for those without content to consume after the New Year’s party.

Going Indie

Doesn’t seem like a hard thing. To be honest, it looks allot like pledging to participate in a ludumdare event. No formalities, no signatures, no contracts and NDA’s. For me it’s more like a state of mind which translates to “Now I can be in full control of my projects and do what I want”. Another way to put it would be like having a cigarette smoker (like myself) saying “Today, I will quit smoking”. It’s easy to say, easy to get into that mental state but it’s hard to keep at it. Most people advice to not take the plunge until you have enough money to sustain yourself for at least 1 year. I think that’s a good, sane idea. I did not listen to it but that’s because I took another approach.

Moving back to my hometown

Sometime in December 2012 I moved back to my hometown after quitting my job at @Gameloft. My mother’s illness really progressed and I was expecting the worse. I proceeded to finish my last year of University/College by commuting to Bucharest almost daily. Thankfully things have gotten better for her since then but she’s not out of the woods. After I finished college I was faced with a huge problem: My funds we’re bellow 0, commuting daily burning all my savings and my folks we’re in the same boat. I couldn’t afford to move back to Bucharest and search for a job (renting an apartment there is expensive for Romanian Standards and you have to pay at least two months in advance) so I decided to make the best of it.

The bright side of things

The idea was to try out the indie life, make a game, release it and see if I can in any way afford to live off of it. My goal was simple: Make enough money from my first release in order to afford to buy a pack of cigars daily for one month, and two beers each weekend. The total sum amounts to: 105 euros. If I could reach this goal then there might by a chance of being able to turn this into a viable business.

By moving back home I don’t have to worry about paying rent each month, nor having to buy food or pay for transportation, which allowed me to focus on one project full time with no other distractions. Living in Romania also provides a huge advantage as, compared to other countries, the cost of living is relatively small and I can get away with earnings that otherwise would be considered less than sufficient in other places.

The project – Mutant Gangland -

Last July I took part in the Mini-LD hosted by @sorceress, #7DRTS challenge. I wanted to go head to heads with a friend of mine and ex co-worker @Radu Chivu. In the end we both took part but only for two days. I ended up with a messy and sluggy tbs which I dubbed Mini Wars. I was heavily disappointed in my creation and set up to remake it (more details on that here). First rule of order was to fix the broken pathfinding implementation I used and design a proper AI.

With a bit of luck I manage to get @Thomas Nopper’s attention and enlist him to help me out with the graphical assets of the game. Over the course of 6 months Thomas waved (and keeps on waving) his magic wand at the screen and kept on producing new graphics and sprites for the game, while I kept tuning, balancing and polishing the game. Looking back on it, things have changed quite a bit:

mutant_gangland_evolution
Continue reading

Mutant Gangland – road to v0.2.6

indieDB_header_small

It’s been more then a month since the last update and this is due to us working hard on getting the game ready for the 12 days of indie stream. Now that the AmbushedGamer hosted event has ended we can start pushing updates and posts about the changes the game went through, the new additions and future plans. The AI posts will resurface once I’m done balancing the unit special abilities (healing, empowering and self-destruct). For now, here’s a brief change-long since the last post:

  • Units received new “racial” abilities: All mutants can heal themselves during their turn, and robots can be armed to self destruct on impact.
  • Top tier units (Bam Tanks and Mechs) can now sacrifice 50% of their initial HP to empower units in close proximity, by boosting their attack and defense stats for one turn.
  • The User Interface went drastic changes, having remade them twice till now, with one future re-skin planned.
  • Victory conditions for normal battles have been updated. Unless otherwise specified at the beginning of a map, victory is achieved if the enemy has no more units available on the battlefield and cannot produce new ones during his turn.
  • Commander stats have been tuned. They no longer have 2/5 points in each stat + a preferred stat, and their tactics are strongly influenced by this.
  • The game now contains two new sound tracks (courtesy of @Grace Zarczynska) and lots of sound effects.
  • Changes have been applied to range attacks. Ranged units can now attack from their location if the targeting reticule (cross hair) flashes green (indicating they are well within their range).
  • The AI focuses less on creating scouts during mid or late game and will try to balance a ration of units present on the battlefield.
  • A unlock system and a war room are getting slowly integrated into the game. Levels and commanders will be unlocked by completing objectives (winning a map by not capturing any factory, winning 3 games in a row, etc)
  • Hotseat/local multiplayer can now be started from the commander select menu.
  • Players can now export their battle details from the victory screen and visualize the data from the war room.
  • The game content and ui elements now adapt to any resolution.

Whit that being said, I have uploaded a video here showcasing the progress and a battle on a new map (designed initially for the 12 days of indie). In the next update, we hope to include a new UI re-skin, the war room and objectives. The game’s release date has been moved to early 2014 (January most likely, but only if we manage to get two weeks of play tests with no bugs or performance issues).

Here’s a bonus image of the commanders:

Commanders - both colors for both players

MGL Commanders

Let’s talk about the Graphical Update

About the graphical update:

While I was neck-deep in code Thomas decided to revisit all the graphical assets for the game and boy did they change. Both factions got a huge re-skin and the terrain tiles and buildings were updated. I now play the game, almost exclusively, on the 3rd zoom level, just so I can see the little murder machines up close. All the units come in two colors, blue and pink allowing each player to play as any faction he chooses. Battles can be fought between mutants and robots, mutants and mutants, etc.

About the commanders:

As stated in the previous news post a new, big, gameplay addition were commanders. There are 8 of them in total, available for both players. 4 commanders for the Mutant Faction and 4 for the Robots, each with it’s own bonuses and play style. Even better, commanders on the AI side have started to receive their own AI scripts. Thus those with bonuses to the income might prefer to spend the first 3 days conquering buildings and the following 5 chasing the player with their Mech’s. Defensive commanders will prefer Tier 3 units (Attaka’s or Killbots) instead of costly battle-tanks while others might take a more balanced approach. This is pretty much still work in progress but things seem to move along nicely.  Have a screenshot (their portraits are placeholders. For now…):

Terrain Modifiers and game modes + ui updates:
To go along with the new tile graphics I’ve added terrain modifiers. Each tile can boost or lower a unit’s defense. Standing on plain sand will not stop a bullet but a forest might. And what about the game modes? Skirmish has finally been implemented. As opposed to the normal mode, in Skirmish you cannot build units. Both players start with a pre-defined set of units and must battle it out. The player that runs out of units at the end of the battle looses.

Now, the UI is also undergoing a few changes. Since my goal is deliver a TBS to be played in quick session I dare not have loading screens. The goal is to get you in charge as soon as possible and the new UI is being updated with this thought in mind. As with all other things, it’s still a WIP and will undergo a major reskin once finished. Here’s a gify gif gif:

That’s about all for now, but stay tuned as more updates are to come in the following days.

P.s.

Here’s a video with the skirmish battle: