• ### Announcements

• entries
8
0
• views
156

Blog about the journey to indie game development

## Game Design Document, Scoping, Prototyping

In the monthly progress post I figured I needed a Game Design Document (GDD) before working on extra features. It would be a waste of time working on features when I have no clearer picture where the game should evolve to.

The first thing I did was searching for online resources. I have found a bunch, and decided to share those on a page dedicated to Game Development Resources for other game developers.

While working on the GDD I noticed it takes quite a lot of time and it is easy to get lost into details for a long time.

Then, after a week or so, I came into contact with a guy named Richie and he had the tip that I had to scope my game into 5 minutes of gameplay.

So in 5 minutes, the player has to know:

• what the game is about
• the basic mechanics
• if it is fun to play

With that I began to look at the GDD I made so far. I immediately noticed that I had way too much material for 5 minutes of gameplay. Obviously this is because a RTS game has several phases. It would be easy to discard the 5 minute thing, but I wanted to follow it though: what would be the essence, the end goal of the game?

Together with Dorus Verhoeckx, someone I work with together on our own products and dreams, I started stripping all stuff that might be ‘distracting’ from the main objective. This meant base building is minimized (2 buildings left). Resource gathering was cut – just get money from structures. Have only 1 unit type. Etc.

This was done on paper. A lot of stuff stripped and the core objective exposed. Then I started writing down what was left to do to get this into a working prototype:

Prototype, with todo’s on the right. Lots of the has been crossed, since I worked on them lately

So what is the essence? Domination in RTS games. Conquer specific structures, hold out long enough to score domination points. Resource gathering? I ditched that in favor of getting money for specific captured structures. (not all captured structures give you ‘domination points’ though). You play 5 rounds of 1 minute. After 5 rounds – the player with the most domination points wins!

Is it a good idea? Is it fun? What about all the other cool stuff I wanted in my RTS game?

Well lets first see to finish the prototype – I want to get it out before the end of the month. I’d love to hear how you guys think about this kind of game. And if you’re interested in testing out the prototype just let me know at stefan[at]indienamic.com. Then, after that I will decide if I miss stuff, want to re-add things and further iterate. My expectation is that there will be quite some iterations / prototypes / refinements before the final ‘game’ mechanics are there.

## First peek at prototype

What? A prototype? Let me elaborate about that in another upcoming blogpost. But for now, just enjoy the screenshots:

Under attackAttacking enemy baseConquering a sub-base…

For a long time we could have done without loading map as we used a Random Map Generator (RMG). Random Map Generation is awesome because you don’t need to worry about any dynamics from that part and can easily test some basic mechanics. For reproducibility and to actually build a game (you want to play on fun maps right? ) I needed something to load up into the game.

For now we pass a parameter to the game called map:<filename> which loads up the <filename> . If you don’t provide a parameter the Random Map Generator is used. And if you want you can now influence that also a bit via rmg:map=<width>x<height>;human=<starting credits human player>;cpu=<starting credits cpu player>

To do this we used the an AbstractFactory pattern and we had to extract some logic from our PlayingState class. More on that in the in-depth video (for Patrons only).

## Demo

Do you like it? Any suggestions? Let me know!

## Monthly Progress Summary #1 (Augustus & September 2017)

When I started this journey, I wanted to be transparent about when working towards my dream. I’d share my challenges, achievements and reflections.

This post is a ‘monthly progress reflection’ blog. I’ll look back a the goals I had set and then reflect what has been done. This means numbers (stats, money) but also general insights.

This post is actually the “month and a bit of the other month” progress report – as the beginning of my journey started in half August.

## What where the goals this period?

In this blog post I started with a plan of attack. Looking back I realised that I did not define features to build in this period. No wonder, since structuring the plan was done later. I did have, roughly, the following goals for the ‘shorter term’:

• Finish up harvesting resources
• Add a few more core features to the game (with Dune 2 graphics as placeholder)
• Set up a new company/identity, its social media infrastructure and update Patreon accordingly
• Get to 50 visitors (not views) on this new site
• How? Blog about as many things I can that have been done. (I do not want to blog about what I am ‘about to do’)

### What is achieved? Numbers!

• At the 13th of September 2017 Indienamic went live, along with a Facebook page and Twitter account
• Finished 4 core features (I did not blog about all of them yet)  🤘
• Made 4 demo video’s 🤘
• Made 2 in-depth videos for Patrons only
• Published 4 blog posts on Indienamic, and 4 on stefanhendriks.com🤘
• Indienamic has had since its live-date: 162 visitors and 325 pageviews
• An unknown amount of visitors have been visiting stefanhendriks.com about my harvesting resources blog. Since I am unable to distinguish those who came for the game or where there for my (other) technical blogs I will not count these visitors/page-views.
• Games released: 0  (just kidding)

### Costs:

I have spent ~87 hours in August and September. Most hours spent by taking leave of my freelance work. I see this as an investment. As a freelancer I have a decent hour rate, if I would have spent this time working for that rate I could calculate that as ‘invested money’.

### Benefits / Revenue

So far Patreon is the only source of income for this adventure. In total Patrons donated 5 dollars in August and 6 dollars in September. Thanks, you’re awesome!

## The end-goal

Become a full-time indie game developer. Earning money from my games and/or journey to create them. Patreon fullfills a role in the journey part, as you can support me. Selling games would be the other part of the dream. Where and when to sell still need to be figured out.

## What about the release date?

In the plan of attack blog post I mentioned the 29th of October for an Alpha release – with Dune 2 placeholder graphics. Currently I think the (final) graphics should be derived from the Game Design. By postponing the ‘graphics problem’ I noticed I’d be delaying an important aspect: what will the game exactly be about? So I have decided to tackle this question first. This has impact on the release date for an alpha. How much, I will elaborate further in another blog post.

## Milestones

Since I’ve given myself 12 months (end-date is 1st of September 2018) to get to my end goal, I’ve defined the following sub-goals/milestones:

• Produce a clear picture of the game, how it will work, etc. So, a Game Design Document should be produced.
• Produce graphics, sounds (depends on GDD)
• Engine feature complete (requires GDD to know which features)
• First alpha 30th November 2017
• Publishing, how to earn money from it (requires all of the above)
• Marketing wise: Get to 12k visitors at 01-09-2018 -> 5k visitors at 01-03-2018 -> 1k visitors at 01-01-2018, 250 visitors in October 2017

## What are the goals for October 2017?

• Produce a first version of the Game Design Document
• Up to 250 visitors in October
• Produce: 3 blog posts
• Fix attacking, it is broken
• Work on 1 engine feature (depends on GDD)

The GDD is very important indeed. I can work on as many engine features I want, but as long as I don’t have a clear picture of the game I cannot produce it. I’ve been working on and off on a GDD for the past few days. I hope to complete it soon and share with you the first results.

## Conclusion

The past period has been a busy one, it had more focus, and I can get more focus by getting my GDD finished. A date has been set for the Alpha release and with a GDD I can more deliberately focus on the features to get an Alpha ready at that date. Next month I’ll reflect again and share again some numbers.

## Incubator week reflection

In this blog post I look back and reflect on the recent the incubator week and share with you how it went, what I learned and the overall experience.

## Intention

Work through as many features as possible and look ahead, set some goals and have some ‘alone time’.

## Preparation

I greatly underestimated preparing for this week. Packing my stuff (clothes, but also equipment for working, etc) took way more time than anticipated. My ‘excuse’ is that I just came back from a holiday, but even still, I could have planned that better. Another way would be to reverse the order: first do the incubator week and then go on a holiday

## How the week progressed

I booked a small appartment for a mid-week since I can’t work for a long term at home. (I don’t have space, all the rooms are taken by the kids.) The location booked was good enough for me. Free wifi, enough power. The beds where pretty bad, I never had a good night sleep. Another downside was that I could access this location at 15:00 on the first day. This meant I had to work from home (which was suboptimal at best) at first. Combined with my poor preparation it meant I effectively started at 11:30-ish, which is valuable time I have wasted.

The first two days where focussed on building features. That was the period when Arjen joined me. Working with Arjen kept me focussed on building features for the game. We enjoyed working on the game, and we had to make sure we took our breaks. I liked working with someone else on the game. Compared to doing it alone is that you can have sparring sessions, and get valuable feedback.It was very nice. Thanks Arjen!

When Arjen left (at the end of day 2), the next day was sort of ‘new’ to me. It has been years since I had so much time to reflect. First I recorded a demo (the Harvesting resources demo) and create the extensive video about implementation for Patrons only.

In between I had time to think, and I reflected on the years back and the goal I had set to write my own game and make a living out of it. One of the things I did not like in the previous years is the lack of my own location to develop my own games. At that moment I thought about how I would like my ideal ‘company’ to look like. In fact how my ideal life would look like if I could have it my way. In the end I decided to set another long-term goal (12 months) to get myself my own office (at/in the house preferably). Today I am in the process of looking for another place to make this goal a reality.

In the end, the incubator week effectively was 4 days (not 7). I booked something mid-week. Next time I would definitely book for 7 days.

## Conclusion

The incubator week was fun. You get a lot of energy when working with other people and you can really achieve a lot in a short period of focussed time. I would repeat this process for sure. I have yet to decide how I will combine this with the other goal of finding a new office, as it takes time (and thus money) as well. When the new incubator is planned, you’re surely read about it here.

Finally: If you want to build your own games, allocating time and doing it is an awesome way to get stuff done.

In the incubator week Arjen (thanks Arjen!) worked on the minimap feature. It was a bit tougher then anticipated, but the end-result is very nice!

Every since I played Dune 2 I wanted to build my own RTS game (which I did, twice). I always found the minimap a very handy feature. Since I’ve used it quite a lot I want the experience for every player to be flawless.

When hacking away at Dune 2 I noticed the map sizes were always a power of two (32×32 or 64×64). The minimap itself had a max of 64×64 pixels, so each tile would be 1 pixel on the map. If you played on a 32×32 map, the tiles would simply be pixels of 2 by 2.

Dune 2 in action with 32×32 minimap

## How we wanted the minimap to work

• Ability to render very big maps (4096×4096) in the minimap area
• Ability to handle ‘awkward’ map sizes (ie, not power of two)
• Ability to handle very small maps (32×32)
• Minimap would be available only after building a RADAR
• You would need sufficient power to see anything on the minimap

## Demo

See the minimap in action here:

64×64128×128

83×57256×64

## Improvements?

For now we’re satisfied, but we already have a few ideas to improve further:

• a zooming possibility
• gradually decreasing minimap with  low power? (introduce more ‘static’ ? slower ‘update rate’ ?)

Special thanks to Arjen van der Ende for his time and dedication to make this feature into reality during the Incubator week!

## Adding Power to my Strategy Game

In the incubator week I built another ‘resource’: electricity, aka power

## What does the ‘power’ resource do?

Power is mainly used to limit the players abilities and have consequences building structures. Power plants produce power, other structures consume. This way you need to balance out your spending. For instance in Dune 2 Rocket Turrets are very effective defense mechanisms, but they cost a lot of power resources.

In this game I built the following limitations when a player consumes more power than that is produced(consumption > production):

• construction speed is reduced to 50% of original speed
• harvest deposit speed is reduced to 50% of original speed

I can think of other negative effects for ‘low power’ scenarios, and I’ll experiment them along the way. Without these negative consequences there is no need to build power producing entities at all. Their role is to restrict you in a way and think a bit more how to spend your money.

## A few thoughts about Power and ‘Food’

There is a distinction between “food” (which limits how many units you can have) versus “power” in RTS games. Where power brings limitation in game mechanics, like slowing down production of units or not able to use. Other games, like Warcraft use a food aspect. You need to build farms to increase your capacity to build your army. And even food supply has a max amount. Command & Conquer does not really have a hard food limit shown to the user, although there are limits. I think a ‘food’ aspect, is a great way to make a player think about when to expand your base or when to expand your army.

## Estimation

This feature was estimated to take ~ 4 hours. It actually took around 8 hours to build.

As you can see, it is very easy to be optimistic with estimations.

## Demo:

In this demo I’ll show you the feature live along with a dive in the code!