Freitag, 5. Dezember 2014

CamoTactics Update: Improved Sound, UI, Plants, Chests, and more!

I made good progress on CamoTactics. I settled with a decent UI style, improved sound (you'll love this), created a ready-for-action mission system, including general polish, amongst more. The next release is planned towards end of December or start of January next year. Till then, you can download version A1B5 build here:

CamoTactics Alpha 1 Build 5


Sound is finally played directionally or in stereo. Different sounds are used depending on your distance to the sound played. In other words: an explosion in the distance has a more damp or dull sound as one played up close. This can be extended to all sounds, but it'd make only sense for really loud ones (gun shots/explosions). The result of this however is really amazing and has enhanced the gaming experience  A LOT.

Mission System

The mission system I prototyped before A1B4 release has been finished to a state it can be used to create mission based gameplay. As far as I'm concerned, I should be able to do most if not all functions a decent mission requires. For example, I can make enemies spawn if certain conditions are met, let a dialog pop up, start a new mission, kill off one entity, add HP to one entity, and so on. The player receives reward upon completion, and you can also fail your mission (even if you dont know you did - this still needs decent UI feedback).


AI Improvements & Other Additions

I've experimented with AI, improving targeting by taking sensors into account, and adding a simple zombie bot. That zombie bot is going to be the base of all AI I'm going to make , and I've prepared a solution for pathfinding already. AI is still a huge deficit in this game. To the left you see a squad of enemy soldiers being spawned once you enter a certain area (There's a missile in white shot from an friendly AI bot about to hit them and kill them all).

Other things that were added are chests, death avatars, plants that grow and are harvestable, (still buggy) melee weapons and fire modes, customizable weapons (you can use that already), a prototype skill system and a new HUD. As for general polish, the screen is shaking now if the player is close to an explosion and improvements to UI components have been made. I've also implemented mouse control to the game. You can aim and use most components, including the inventory, with it

Current Progress

I'm currently in the process of reimplementing visual effects such as explosions, muzzle flash, and other particles. Doing this I've noticed many flaws and unnecessary complexity in the visual controllers for entities. I'm in the middle of implementing a complete new, much more simple and flexible system. It allows me to do some neat things in the future as well.

Despite of some delays the game is getting forward and I will keep pushing it forward. Considering the progress, I won't be able to finish this game with complete story for the planned release in February. But I think it is realistic to say that till then, it's going to be out of alpha stage with one completed game mode (likely tower defense/zombie mode) for sure. There are still a lot of things to do in terms of AI, doing missions/levels and the story itself.

Until February next year, I expect to have a decent AI, most of the planned UI screens,  and a working skill system in place. Improvements I want to realize till then mostly surround camouflage mechanics, shaders, camera/viewport, dialogs. Also: more content.

Donnerstag, 4. September 2014

CamoTactics Update: Pixelart, Particles & Inventories

It's been silent around CamoTactics lately.  I've been going on and off track from game development during the last two months. Part of that was caused by family meetings, the other by motivation issues.

As of recently I've been eagerly working on new features however, and there are plenty! Example: some first drafts for ranks/levels/skills/factions, size based inventories, a new way of handling graphics, customizable weapons, freshly awesome pixelart, particle effects, a new main menu and also basic in-game dialoge. All of this goes with some heavy optimization here and there too!

 The main menu is now animated, with moving tank, ground camo and particles. This screen and the UI still needs a lot of work.

 Inventories support multiple item sizes and weapons can be customized. You can also switch between the character's inventory and the inventory of the vehicle you're currently driving.

Experimental particles have been added for shooting and traveling over different terrain types. Looks promising, but that system requires better code.

Despite of the break I am very happy with the progress, and there's a good chance this game is going to get finished! The next release is planned on 19th September, so stay tuned.

Thank you for reading!

Samstag, 12. Juli 2014

Camo Tactics Alpha 1 Build 4 released!

Alpha Release 4 is out! Get it on GameJolt or Indie DB!

CamoTactics Alpha 1 Build 4

Many features were implemented and I worked off all planned items, including some that I considered optional. Interestingly, most of this was implemented during the first two weeks after release 3, and that productivity spike sadly slacked off in the following two weeks. I am still very satisfied with the progress I made this iteration. To recap what I wanted to implement this month, here is the full list:
  • [DONE] Make installation easier. There's multiple ways to do this (installer or bundled jar) and requires more research.
  • [DONE] Extend UI functionality (preparation for main menus and missions)
  • [DONE] Get rid of the prototype-ish graphics and replace them with better ones.
  • [DONE] The early prototype of this game included a very simple "camouflage" system which gave combat an interesting twist. This system is going to be re-implemented.
  • [DONE] Performance and usability improvements
  • [DONE] Many bug fixes (primarily inventories, weapons, sound) and internal improvements
  • [DONE] adding some first particle effects
  • adding infantry
  • mounting vehicles
  • [DONE] more advanced AI

I have a lot of plans for the next build already, which is going to be scheduled for 16th of August. On my list are:
  • "Walking" AI. So far I only have one for immobile static defenses.
  • A first stub of the Tower Defense Mode, as attacker. I can possibly get that one running till then.
  • A first stub of the Mission System.
  • Playtesting revealed I need better possibilities to take cover. Infantry is going to be a lot more fragile than tanks, so this is VITAL. For this I'm going to use obstacles such as trenches or bunkers as "sensors", and these sensors reduce damage or even have the chance to eliminate a projectile if it touches that sensor. This can be different to each projectile type, such that Missiles aren't able to travel through a wired fence, for example.
  • Reimplementation of Infantry. Infantry was not adapted to gfx changes made prior alpha 1 build 3 and thus taken out of the game, so I'm going to reimplement them next update.
  • Infantry mounting tanks (later vehicles).
  • Many internal improvements, cleanups and bug fixes.

Optional list is:
  • Play around with armed motorcycles.
  • Consider overheating as additional weapon property.
  • A "size-based" Inventory, rather than grid-based: Larger items are larger in inventory than small ones.
So how is Camo Tactics going to look like when done? For some answers, please refer to this post.
I am very excited with this game, and I hope you are too. Thank you for reading!

The Future of CamoTactics

The CamoTactics release of Alpha 1 Build 4 is imminent! Some of you may have wondered what exactly this game is about and where it's going to go. Fear not, for you will find answers here!

Game Structure:

I am likely going to use a Mission - Mission "Debrief" structure for this game. You do missions and get back to the mission screen to proceed to the next mission. In between, you can place items in your personal storage, buy or sell weapons, ammo, and other items, or change your equipment. This can be integrated with most of the planned game modes.

Game Modes:

Planned modes are:

Tower Defense mode. You can take the role as either defender or attacker. It may include zombies (grinding zombies with tanks?! Omg!1!one!).

Arcade mode. This is giving the player more freedom to try all available weapons, camos and vehicles, and it's going to be very similar to how the current alpha build works.

These two will definitely be in the final game. Ontop of this, I have multiple other game modes I can extent on.

Strategy Mode. I recently implemented a "death cam" that lets you scroll around the map after your death. What I could do is letting you send orders to friendly NPCs and even control them.

Campaign. The campaign itself is going to be story-driven and strategic. You will have to sneak through or shoot yourself through different levels. This is frankly where the game can possibly explode in terms of effort and time. Since I've never done a game with story before, I'll reserve the right to cut off the campaign and simplify it if I feel it's not fitting to the schedule.
Should I not be able to add a story at all, I'm going to let enemies drop notes containing some of the story in arcade or tower defense mode.

I can also directly integrate this into different game modes. Say, if you collect weapon X in the tower defense mode, you can use that weapon in the campaign. If you bought weapon X in campaign, you can use it for tower defense mode. Your inventory of that particular game save will apply to all these game modes (except arcade). So if you want to progress well-equipped (i.e. if you're playing on hardest difficulty), you can do some grinding and have some variety at the same time.

I yet have to experiment with this type of game design, but I think with the right balancing it has the potential to make the game more fun.

Other Gameplay: 

Combat should resemble real life combat. You take cover in order not to get hit. You use camo in order not to get seen. Your weapon behaves like a real life weapon would: it has recoil, a base bullet spread, and it also breaks the more you use it. Weapons will also be customizable using different attachments.

I'm keeping the possibility open to customize your characters as well, but I am not sure in what detail this will be implemented.

Mittwoch, 11. Juni 2014

Camo Tactics First Alpha Release

Camo Tactics Alpha 1 Build 3 is out! Get it here:

 CamoTactics Alpha 1 Build 3

This build is indeed playable and confirmed to work on W7 and an antique netbook running Win XP, but a bit of an effort is required to install it correctly. I encountered issues during release preparations and they sadly bursted my plans of the release date to be scheduled in the first week of June. Eventually, I decided to provide a quick and dirty solution for the sake of sticking to my deadlines and just provided detailed install instructions. Do not worry - this is not going to stay that way.

 At the moment, the gameplay very is basic - taking damage, shooting, reloading, picking up items... - as is the interface. Some nice details were added (i.e. overlays when taking damage, day and night cycles or fuel consumption) but these yet have to take their full shape as the game is being developed.

Version A1B3 Game Play - Indie DB

The next playable build is scheduled for 16th July and by then, it should have the following minimum features:

  • Make installation easier. There's multiple ways to do this (installer or bundled jar) and requires more research.
  • Extend UI functionality (preparation for main menus and missions)
  • Get rid of the prototype-ish graphics and replace them with better ones.
  • The early prototype of this game included a very simple "camouflage" system which gave combat an interesting twist. This system is going to be re-implemented.
  • Performance and usability improvements
  • Many bug fixes (primarily inventories, weapons, sound) and internal improvements 

If I have enough time, the following is also planned:

  • adding some first particle effects
  • adding infantry
  • mounting vehicles
  • more advanced AI

Thanks for reading!

Mittwoch, 4. Juni 2014

One Reason why Companies fail

From stories and own experience I know and have heard much about companies and their sometimes questionable way they treat their employes; and simultaneously, complaining about decreasing productivity and/or revenues. In this article, I want to describe possible threats and offer solutions. Be aware this only covers one aspect of leading a company successfully, and it may not be the best/most practicable advice - I am no CEO after all - however, I think I am still able to deliver some insight and thoughts for you, no matter your background.

I want to examine the leadership-employee relationship more closely. Leadership, communication, feedback and team work: All of them are connected with the other. So what can you do to create a good company in this regard?

Leadership. For one, what your employees think of you is very important. Companies must be lead by example. Employees will adapt to negative and positive behavior alike - the former is something you want to avoid, the latter something you want to promote. If you as a CEO do not seem to be doing your job, this likely is the behavior the employees are going to immitate. If you want people to see and value work, you must communicate with them and for example, arrange meetings for work status reports; Or make them write a short list of what they have done today at work. This is also handy if you want to see what your employees are doing in the first place.
Be aware that every routine and meeting you make your employees do, you should also do yourself. In return, they are more likely to do actual work instead of just sitting around doing nothing, which sadly happens quite often in larger companies. This also has the effect that you can easier recognize whether a routine or meeting you made them do/attend is reasonable. If it's a waste of time, why doing it? If you participated in the meetings you have ordered and came to that conclusion, then it's best to get rid of them - the faster the better.
Optimism and problem solving is another important aspect of good leadership. If you are hopelessly optimistic about your horrible revenues or sales then you'll have a credibility problem. If you are hoplessly optimistic about your horrible revenues or sales AND have multiple business plans and strategies to get out of that situation, then employees may find you're the right person to lead that company.

Offer your employees the chance to give feedback on your production or employment methods. This is important so you can react on potential problems appropriately and avoid them. You MUST in any case take this feedback seriously. If an employee points out a serious problem and nothing is done to solve it, the message you're sending by ignoring it ("I do not care what you think") will spread fairly quickly through all departments of your company, thus making communication between leadership and employees extremely difficult. What's also important is that 1) solutions for one problem must be as effective as possible and 2) if your own behavior is the problem, stand up for it, change it and do NOT not shove that responsibility to your employees; If this is not granted, your employees will start questioning your competence, and this is something you want to avoid under any circumstance.
It takes a lot of character to recieve criticism and change, but keep in mind making mistakes is natural and necessary. You as leader AND your employees can make mistakes if attempts are made to change the situation (and ideally, succeed doing so). Make your employees aware of this. There is no point in pretending as it hinders employee satisfaction and potentially company growth, so be truthful and honest and ask for the same in return from your employees. Make your employees aware of this, too. Always remember: being part of a company means you are part of a big team that works together in order to do a living. If a company is successful, it's not only you who contributed to the success: its the entire work of you AND your employee - and possibly of any employee and leader who has worked here before.

Feedback. How should feedback be recieved? Ideally, feedback should be delivered in written form through a person of trust, or directed to the CEO him/herself directly. Sadly, if the "right" people come together, unanonymous (constructive) criticism may lead to internal fights you want to avoid. This is why most companies offer feedback options through anonymous forms or letters.
The letters should be designed in such way your employees can get over the "barrier" of submitting one. You can lower this barrier by daily reminding employees to give feedback, or make it a daily routine to write a round of feedback letters after a meeting (and also participate in it). You can also place the forms/letters to a location where it's visible and many people pass by (i.e. next to a coffee machine) and also have the possibility to sit down and write. To add up importance to these forms or letters on a more subconscious level, you should "decorate" the location a bit and spice it up; ideally in a way it's only noticable when you're aware of it (no Santa Claus statues for you! Maybe a little plush or mascot would be nice however). Do NOT ever place these forms in a lifeless corner of a room where noone notices. The Uni I'm studying at has their feedback submission box attached to a wall you normally don't look at often, and is surprised why no one ever bothers giving feedback. As a consequence, they hardly know about the mess that's going on in their own faculty.
Another option to give feedback is to offer surveys using ethernet/internet, which probably has the lowest barrier for office jobs. You're welcome to find your own ideas here, but always consider it from a employee's perspective.

Communication. Always keep in touch with your employees. Go around the work place from time to time, not necessarily to monitor their work, but to detect problems or maybe also opinions about you, your company, or anything company related. Be keen to keep a good relationship with your employees. Get involved, get to know them personally. Make sure the employees will get to know eachother and establish good relationships with one another. For this purpose, you can organize company events once in a while, i.e. attending a soccer match, going to a restaurant and so on, IF it fits in your budget. Or you can organize such events in from of a reward if the company mades more revenue.

As leader, do NOT ever be passive aggressive towards your employees even if you have a good reason - you'll make the impression to favor/disfavor certain people. Favorism only leads to internal fights and arguments, as people will attempt to please the boss as much as they can (and some will also go over dead bodies for it) instead of doing actual work to get promoted. The footprint these kind of people leave behind is not one of competence and leadership, but strive for power and possibly abuse. That's the kind of people you don't want in leading positions, because once they got there, they'll try to bring hell to their "opponents"; this only leads to discrimination and internal division.
Instead, try to be as objective as possible. Take people for the fact they are a human being just as you are, a being that deserves any kind of respect and dignity. This also means that if you are better AT something than them, that still does not mean you ARE better, or have a higher value. You are still human, regardless of your role or skill. Everyone should have the possibility to get promoted or get a leader position, if their social skills and craft seem fit for the job.
In my opinion, this is one of basic requirements to lead a company - if you cannot do this, you should think twice of becoming a CEO of any kind; Not because you wouldn't be able to lead a company, but because you will stumble upon a lot of talent hidden behind skin color, burqas, turbans and possibly vaginas; Talent you would otherwise miss if you are slave to your own prejudices. For every missed talent, you miss a chance to improve your company's endeavours. For every discriminated individual, your employees will lose trust in you, and possibly add up bad karma that will be retaliated one day or the other. Build up positivity, not negativity!

Even in a capitalist system, the value of each human cannot be expressed by money. Maybe work force has a monetary value in a market, but life is invaluable. And so is talent and skill. Hence, treat your human resources right, and it WILL contribute to the success of your company as a whole - EVEN if they're not the most competent ones!

Donnerstag, 8. Mai 2014

CamoTactics May Update: Weapons

So what's new in CamoTactics?

Changes usually were internal of nature (improving architecture and everything around it) but I added gameplay and utility things. This includes:

  • A semi working UI for display purposes
  • Each entity now has an Inventory
  • When reloading, magazines from the inventory are used (= a weapon always has a magazine attached to it)
  • Weapons get damaged each shot. Dealt damage decreases as weapon durability decreases. Repair kits or cleaning kits can be used to repair them. Maybe I'm going to separate between damage + "clean"-ness if it's not making the game too complex.
  • Critical hit chances are implemented into the mechanisms (but don't affect gameplay yet as they're using a default value so far)
  •  Energy/Fuel meter.
  • Prepared for loading item models using XML files
I roughly estimate the game to be finished by 60%. A lot of stuff has to be done for rendering optimization and AI. Item/enemy spawning, missions and the ability to place (terrain) objects yet have to be added.

I think it's best to draw a line once above mentioned features are implemented. My top priority is getting this baby done, and it's going to be my first finished game too.
This is also the first time I'm creating something pretty decent from (semi-) scratch. Rest assured, after the first "finished" version of Camo Tactics it's not going to stop just there by developing its multiplayer version, CamoTactics: Online. It is a relatively small game and not taking advantage of that fact would be a shame.
As far as my networking knowledge goes, the game's internal structure at least shouldn't make adding multiplayer a complete nightmare.

Mittwoch, 23. April 2014

When games become "saturated"

UPDATE [24.02.2017] As of Minecraft version 1.11.2 much what is described here does not apply anymore. For example, survival and exploration mechanics were balanced and it has become quite enjoyable for me.

Recently I stumbled upon an interesting comment on youtube. It was about how adding too many features may spoil a perfectly fine game. Unfortunately I didn't save the link to this comment, as I would have never thought I'd ever pick it up to create an entire post about it. As I started to see the same pattern on other games, it indeed made me think about how some games progress as a product and subject of design.

I will describe in my own words what this comment was about and give examples. Please note this post should not be taken as "you should change this immediately". This is merely an analysis/opinion people may learn from (or not).

During a game's alpha phase, it's fun to see it grow and develop, each update adding more content and creating new experiences for the player. However, after a while some games start growing beyond the point they are supposed to be growing.
This state I'm talking about is reached once the developers begin to add more and more content which "disrupts" the original idea, feeling or atmosphere of the game. To a certain degree, change is necessary and part of the development progress. However, many "disruptive" changes may result in a complete (intended or not) reinvention of existing game design, atmosphere, or experience. This is where you, as a developer, have to ask yourself whether you are still developing the game you wanted, or still making use of the atmosphere and creating experiences the game is supposed to create.

One example that was mentioned in the comment was Minecraft. I absolutely loved playing this game when I bought it in alpha, in fact I still have some ancient maps, including the first world I ever started. I still remember well when cake and sandstone was added to the game, and those little add-ons I perceived as a pleasant addition; same applies for breeding. A lot of features you can keep yourself busy with were added. But sometime during the 1.4 update, I started losing interest in this game. So what made me stop playing?

One main reason was that I simply burned out on it. The other main reason was "flawful" game design thus making me lose interest. The mistake Mojang did was adding plenty of stuff to Minecraft that - in its entirety - was difficult to unify in one game to the extent it can still be called "good design". Minecraft offers mechanics such as survival, building, mining, breeding, logic (redstone & pistons), exploration, boss fights, but it really excels at neither. Survival is easy even on hardest difficulty once you managed to build a nice shelter and get some animals or a farm (at least for "older"/adult players). Building (including redstone) gets boring after a while once you build everything you wanted to build; at least for me adding new materials will not change this on a long term. Exploration tends to be repetitive, possibly due to procedural generation. The boss fights aren't too special compared to boss fights in other games, unless you're playing with friends maybe.
In fact, I find myself lost in the amount of features I could possibly use, and I am not even using half of them, either. I realize people may have different experiences or opinions about this, however one must still question whether this is a sign of "bad" game design or not.

A while ago, with the Adventure Update Mojang added multiple features that still somewhat fit to the game (villagers, temples...). With the most recent update they added realms. While I acknowledge the importance of the former, what is the point of the latter? At least I know I'm not going to use this feature at all. The main reason I bought this game years ago was survival, mining and building. Since survival has become easier and easier with every update (breeding, farming, enchants to obtain even more gems etc.), what is the point of playing this game for someone looking for a challenge? I assume this is the reason why Minecraft mods and alternative minecraft-like voxel games are so popular.

During Minecraft's existance, more and more building blocks have been added, most blocks possessing slightly different appearances, but similar or even the same properties to existing blocks. If one block can easily be substitued with another, diversity is not substantially changed as new ones essentially do not add more functionality; other than looking pretty/different perhaps. Alpha Minecraft had a distinct look, but with all the new block types (that often don't even look good or too different to already implemented ones, i.e. stone brick) I think it kind of lost that charme it once had.
But what about texture packs? To be honest, adding texture packs only allows you to bypass the mistakes the developers are held to be accountable for; it doesn't get rid of the root of the problem, it doesn't make the original game design better (maybe better in the sense you can change the looks of it).

What makes this situation worse is that plenty of Minecraft mods exist for a wide range of purposes. For example, if you want to go crazy with factories and extended materials, you install yourself Feed The Best to enhance your crafting/building experience.
Minecraft does not need to add more features; instead it should improve the game mechanics it already utilizes. One step towards this goal would be to implement effects to food, for example. Or put more detail into the survival aspect by introducing energy, temperature, seasons. Then again, the fact that there's probably a mod for this purpose already leaves the developers in a mess.

So what we have here is a "oversaturation" of game mechanics, a lack of diversity; too many substitutes that serve the same function that - in my opinion - has changed the game's "spririt" to the negative as it matured. For further thought, you may ask yourself when the point is reached to stop adding content to your game, or when a mechanic starts changing your game to the extent it's completely reinventing it.

It seems that similar circumstances apply to the game Don't Starve; since I unfortunately did not play the recent versions I cannot really judge; but just by the looks of the new trailers, this game seem to have a similar tendency. Let's hope it will not fall victim of the oversaturation.

So developers: Do NOT over-develop your game. Once it reached a certain "feature-saturation" it is not necessary to add anything more. Focus on one or two large gameplay themes and do them well!

Samstag, 19. April 2014

Critical Analysis: Space Engineers

I want to get a bit more indepth with an analysis of SpaceEngineer's gameplay. If you don't know the game, you should check it out here, it's worth it.

It is possible that in the future some aspects described in this this article will not be applicable to the game as it's being developed. To clarify, this article applies to the 01.026 update released in April 16th 2014.

You may find some of the analysis offensive; in that case, don't get me wrong - I really like this game a lot and it's absolutely promising for an indie title in early alpha; I also realize a lot of what's there is in a very unfinished state. There are multiple things that are still a bit, let's say "uneasy"; on the other hand, other aspects make a good impression, and I'd like to uncover the causes and consequences of either.

What Space Engineers does is to provide a voxel-based sandbox world where you can build, mine and survive in an asteroid field in space. It's pretty straight forward the first time you play it, especially if you are used to other voxel-based games like Minecraft.

It's possible to build space stations, large spaceships and small spaceships from various - partly functional - parts. The latter use smaller voxels (first picture) while the former two make use of voxels twice as large (second picture).

Voxel Sizes

Larger voxels are nice for large scale ships and stations. You don't need to build more voxels in order to get the same size, compared to when using a small voxel size.
However here lies another problem: you cannot pull the same level of detail on large ships as you can with small ones. Larger ones will always look very "rough" with the low voxel resolution that is being used here.
The previously mentioned effect is especially noticable in interiors. Since each voxel is as large as your character, you cannot use voxels for more subtle details. Each level of your space station/large ship thus needs to be one voxel high, plus another voxel for the floor. This causes them to look rather chunky and also limits the player in the creative process.

This effect can be decreased by providing a variety of thinner plates you can walk on that are designed for interiors, instead of using solid blocks all the time. While there are already some thinner plates in game, they are not designed to be used as floors or ceilings, but rather grates or similar.
Another possible solution is to provide something like a "brush size" for voxels instead of just scaling up small voxels: Large spacecraft/stations created with a default brushsize multiplier of 2x, while small ones with a 1x multiplier.

Where to start building?

I felt kind of "lost" constructing my spacecraft, being not too sure what to do or why. This happens to me even when already being used to the game and possessing basic knowledge of the game mechanics. I am not entirely sure of the causes for this, and I can name the following possibilities.

  1. The game lacks purpose for certain types of spacecraft or ship parts, i.e. combat is not implemented yet, thus turrets and combat ships are somewhat useless for now. (You also may end up building something you don't even need as the game currently has no real focus other than building and mining. Of course this will change in the future)
  2. Voxel-based construction of objects gives full control and freedom over your creations and their design, but may offer confusion as well since new players do not know where to start (or with what)
    The interesting thing is: this is something I also encountered developing a ship editor prototype that imitates voxel behavior for StareFire. I guess it's safe to say that creating interior from scratch that also has a function to serve can be very challenging.

    A solution for this problem can be setting up a dynamic To-Do list for each ship that lists up the minimal amount of parts required to create a spacecraft or station. Another solution can be creating large and hollow 3D frame models that allow the player to better plan out interior design. (The players could make these frames on their own with the voxel engine, however they turn out chunky due to the voxel size on large ships)

Construction in Survival 

To the left you can see an optimized version of a small miner I created in survival mode, which took me ages to create from scratch. It's also my first legit spacecraft.

Construction in survival is tricky. Moving around large amounts of ore with an extremely limited inventory capacity is not nice at all and very time consuming. AND that is just for a very small ship. Limited inventory space also prohibits you from constructing large bases and forces you to somehow build a container close to the construction site first, then store all materials there. Larger objects take an enormous amount of material to construct; which in no way you can manage to manually gather as a single person. Construction time of larger spacecraft is not easier either seeing how welding the hull parts in order to finish them takes a lot of time also. The fact that a lot of resources are required to produce hull parts in the first place makes this worse (BUT it should be noted you can adjust production rates when creating the game or editing its settings).
The situation has improved alot with the recent introduction of conveyors and pipes. You can do large bases that hook up refineries to assemblers, and assemblers to a large storage and fully automate unit production. Even unloading and loading transports or miners can be fully automated. Still, starting from scratch remains a pain in the rectal area.

Additional solutions - especially for the problem of starting from scratch - can be the introduction of a tool or small machine, like a little buggy or "wheelbarrow in space", that allows you to move around larger amounts of cargo even if you don't possess a functional spacecraft. Another solution can be to adjust the default production/mining rates.

Destruction and Damage

What I really like about this game is the fact you can virtually destroy everything. Collisions deform spacecraft and asteroids alike, asteroids struck by missiles will crumble, and failing to decently dock to your space station has the potential to damage your spacecraft (or even destroy it).

The only problem I have with this damage system is that it becomes difficult to rebuild already destroyed structures and the fact you need a lot of resources to repair it. It may be of advantage if the ship saved the destroyed parts and enables you to replace them with ease, i.e. just by reconstructing them with the welder.

Other aspects that are slightly unbalanced exist, i.e. the production of solar panels (require many resources to build and basically not even worth using if you're starting out) or the fact you're doomed once you run out of Uranium in your base reactor.
But a lot of things are to come to make this game even better than it already is. Visually it's astoundingly simple yet nice to the eyes by providing enough detail to keep you interested. The fact I rambled a lot about its flaws should not hold you from getting it if you like voxel-based sci-fi games.

Freitag, 18. April 2014


There are a few events that made me stop and think. Like recently I got my hands on an UML modelling program called Enterprise Architect during courses, and also bought the game Space Engineers.
Both of these things made me pondering about the future of StarFire (which is at the moment a floating point of uncertainty for multiple reasons that I will not tell in all detail now). I am considering completely recoding it and make it a shining star in the indie game scene as it was supposed to be from the start.

The aspects I reflected upon are as follows:

  1. Game architecture. StarFire was created to be modular. The development of it was slowed down a lot because of this additional focus on modularity. Another reason was the fact I wasn't very experienced with some parts of coding. A stark contrast to CamoTanks/CamoTactics, which is a game built on the fly (using extracted/abstracted code from the StarFire libs) and thus made huge progress in just a little less than a month.
    Besides this, the game completely lacked a decent specification. This is part of the reason why I still am not entirely sure what to do with it. I roughly know what the player should be able to do in StarFire, but am not entirely sure how it can be implemented or whether it can be implemented at all. In some aspects, SpaceEngineers is very close to what StarFire is going to be. Due to this fact it's a perfect playground figuring out what game mechanics are fun (or how they need to be in order to be fun), before even prototyping them. (I should add that the idea for StarFire was born before I even knew about SpaceEngineers). Like this I think I'm slowly getting a feeling what's best for StarFire and the content I want to display with it. And this is a good thing.

  2. Game design. After playing Space Engineers some game mechanic parts I first wanted to add to StarFire now seem a bit unhandy/not fun enough in practice. This especially applies to gathering resources and crafting/production. On the other hand, some other game mechanics such as voxels I first didn't want to implement now seem more interesting and feasible.

    I have played other voxel based games, such as 7 Days To Die or Minecraft, and despite them using voxel engines they are completely different. First off, Space Engineers, 7 Days To Die and Minecraft differ greatly in the atmosphere and experiences they produce. You will find yourself sneaking around and avoid zombies in 7DTD and run like a pansy once they spotted you; in Minecraft, you'll explore caves, enjoy farming, animal slaughtering and breeding (...this sort of sounds weird but let's just leave it at that). In SpaceEngineers, you will spend hours mining asteroids and creating spacecraft accompanied with epic orchestral music.
    There are no Zombies going to tear down your house in Minecraft, there is not a chance you could tame a dog, farm, or get your house blown up in SpaceEngineers, there's no way you could build a functioning spacecraft in Minecraft with all the fancy space stuff around it.

    Long story short: even using the same technology, the results can be astoundingly different.

  3. Workflow management. Dealing with Enterprise Architect made me realize that StarFire still had multiple architecture flaws that existed from the start. The code itself wasn't a downright mess, it was actually pretty clean and well-documented (considering I'm a bit chaotic), however, in some cases it was very inefficient. This was due to the fact I coded very "light-hearted" without any workflow tools such as an class/workflow diagram, except a TODO list and the occasional but lax diagram/sketch to depict more complex mechanisms. I made these sketches on paper, but I usually never looked at them ever again.

    Sometimes I missed out a flawful architecture in one subsystem because it wasn't depicted with the entire system and all other subsystems (just a small parts of it); as a consequence, I had to invest time coding on both systems adapting them to each other in order to work. That partially also involved recoding large parts of the system. Very ineffective!

I will continue my research, keep on coding smaller games; and when I feel it's time, recode StarFire to bring it to its fullest glory!

Montag, 7. April 2014

CamoTanks Sound Demo

A Camo Tanks sound demo is online:

Features a simple HUD, reloading, firing, and camouflage. FX used from plus a song by me mixed in. I apologize for the horrible quality; I wanted to get a reasonable upload speeds without making the filesize explode and kind of failed.

I'm currently making improvements to the camo mechanic, later on I'll create a better AI for the static machine guns as seen in the video. Finally I intend to make an AI for tanks and infantrists as well.

What's also on my Todo List:

  • Add sprite sheets instead of loading single files
  • Camouflage Skins <--> Terrain Matcher. Terrain and camouflage have an average color, and based on how similar/different they are, a camo value is estimated - Currently it's hardcoded.
  • implement positional sound (sound is played "globally" at the moment)
  • Add powerups (later: items)
  • Day/night cycles: Add a light factor to the camo mechanic. May include some kind of terrain shader as well. (I love when you wander around in the dark in a game only with a flashlight giving you some light).
  • Improve AI further by making it respond to noise a target makes and its visibility
  • Fix physics location not equal to graphics location

Freitag, 4. April 2014

CamoTanks GUI & Sound

So here a short progress update on CamoTanks! Last week I kept myself busy with varous things, such as GUI, gameplay and the occasional bugfixes. The GUI in this game I want to keep as simple as possible, as it is more a source of information rather than interaction (interaction is only for menus). As you can see by the screenshot below, equipped weapons will be displayed on screen, and maybe I'm going to make these customizable. They are also subject of colorization as described in this article.

What also has been recently implemented by me are recoil and spread for weapons, terrain "fluidness" (determine how fast you travel on inaccessible terrain), and multiple fixes for reloading.

I also have added sound already. Implemented sounds are: steps (each terrain type = different sound!), firing, reloading, and an environment background sound. Adding sound to this game REALLY changed the entire feeling of it and it was a very exciting thing to do; to see your game come to life like this. I plan to add more various sounds to make this game even more awesome using the free sound library here (which I strongly recommend using). A video demonstrating this implementation will follow as soon as I fixed some things, i.e. performance needs to be improved and I want a semi-working interface instead of pure text first.

All in all development is going well. The code is surprisingly clean and easy to extend. I suppose this is the positive effect of target-oriented coding; aka coding to get stuff done rather than to think up modular systems (the latter I did a lot while working on StarFire and it slowed me down quite a bit).

There is a lot of stuff I yet want to implement, like adding more detail to the camouflage part by adding a "visibility" and "noise" parameter to the AI . Visibility is mainly influenced by camouflage and movement, while noise is influenced by movement only. The AI looks to the direction it hears sound, and only attacks when an actual enemy has been spotted and is not hiding behind an obstacle.

I also want to let the player mount vehicles and add some survival gameplay. Multiplayer is also planned but I need to look into this more.

Samstag, 29. März 2014

Camo Skins for Tanks

Since I have decided to implement camouflage mechanic to the Tank Game prototype I recently started, I soon encountered one problem creating the graphics for it. Each tank would require its own graphics per camouflage type, so if I had 3 different types of camouflage skins and a total of 6 tanks, I would have to create 18 single images. Most of that work would have been copy and paste in a graphics program and arranging the different parts correctly, which can be very tedious.

So how do you add different camouflage skins to tanks with minimum effort? 

The answer to this question usually is: automation. The idea is to have a tank body/turret shape or outline that is colored using a background image, the camouflage. Then a "shader" image is added to the colored background image to give the tanks some plasticity.

The magenta color is replaced with each pixel in the background image. The shader image is not displayed here but it contains white and black hightlights created with a brush of 25% transparency and 1 pixel size (with max hardness, no anti-alias). The shader image is applied with an additive blending method. The effect of the shader image can be best seen on the gray tank.

The algorhitm used was originally developed for StarFire and was intended to create labels on your spacecraft by modifying 3D textures. I have abstracted it to the extend it can be used by any software or game I'm going to develop in the future.

The result is an easy image merging implementation that spares me the work to create each tank skin individually. I just have to provide a shape along with a shader image and a few background images and the code does the rest. Each of these are very easy and fast to make, too. Maybe I'm going to add some easter egg camos including pink colored skins or heart skins :)