Stefan Hendriks

  • Content count

  • Joined

  • Last visited

Community Reputation

2 Neutral

About Stefan Hendriks

  • Rank

Personal Information


  • Twitter
  • Github
  1. 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] 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. View the full article
  2. 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… View the full article
  3. Loading maps

    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! View the full article
  4. 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🤘 Indienamic has had since its live-date: 162 visitors and 325 pageviews An unknown amount of visitors have been visiting 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) Lets talk about costs/benefits 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. If you like a reflection like this, please let me know. Want to know more details about some things? Leave a comment or contact me at stefan[at]indienamic[dot]com. View the full article
  5. 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’. Achievements Harvesting resources Power Resource Minimap Blogged about harvesting feature (writing blogs take time!) Produced demo video (harvesting feature) Produced in-depth demo video for Patrons only (harvesting feature, in-depth code, etc) Set (sub)goals for 12 month term, in broader terms than only game development Created plans to achieve the goals 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. View the full article
  6. Added the minimap

    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! Brief history about my experience with the minimap / radar 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 We had the following requirements 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: What it looks like with various map sizes 64×64128×128 83×57256×64 Improvements? For now we’re satisfied, but we already have a few ideas to improve further: add the ability to jump to a ‘bigger minimap’ a zooming possibility gradually decreasing minimap with low power? (introduce more ‘static’ ? slower ‘update rate’ ?) Like what we are doing? Please share! Or leave a comment. Thanks! Special thanks to Arjen van der Ende for his time and dedication to make this feature into reality during the Incubator week! View the full article
  7. 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! View the full article
  8. Welcome!

    Welcome to Indienamic! Indienamic is my Indie Game Development Company. Here you can follow our progress in making games and give me feedback. If you like what I’m doing you can support me at Patreon or buy my games. When developing games I try to be very transparent about it so that you can/may learn from my journey. Also I’d love to hear your thoughts/feedback. Your involvement is making the games better! View the full article