# Blogs

## Our community blogs

• 184
entries
• 57
• 29497
views

#### Recent Entries

Latest Entry

In this daily blog (and video)-series I take a first impressions look at the best mobile games that I come by. Be sure to share your favorite mobile game with the rest of us in the comments below!

Battle of Arrow is a first-person horseback-riding archery real-time PVP game - and it has got the most innovative gameplay I've seen on mobile this year (yes, I'm kinda hyped)!

You aim with your bow using the gyroscope, and fire arrow after arrow at your opponent using either a short bow or crossbow, upgrade talents (skills), enhance armor, and new shiny-armored horses. And don't even get me started about the hourly raid bosses!

The monetization is laid-back, with no energy system, and focuses primarily on opening gear-rewarding chests quicker, although there's plenty of free premium currency rewarded through the campaign levels.

Easily the most interesting game I played this week!

My thoughts on Battle of Arrow:

Subscribe on YouTube for more commentaries: https://goo.gl/xKhGjh
Or Instagram: https://www.instagram.com/nimblethoryt/

• 4
entries
• 5
• 625
views

#### Recent Entries

Latest Entry

So, after 3hrs or so of work I have some really cool aimOffset stuff going on with our new farmer.

With this the players will be able to look around and show other players what they are looking at. This can also be used for NPC's to look at the player, hostile creatures, or objects of interest. I am loving UE4 and how simple it makes things like this. Next will be to get the running/walking/jogging animations to do something similar. More updates to come!!!

• 4
entries
• 12
• 437
views

#### Recent Entries

Latest Entry

Originally posted on Medium

I released my first game approximately a month and a half ago and actually tried almost all of the methods I could find on various websites out there - all of them will be listed here. With this article I want to share the story of my “promotion campaign”.

The very first thing I did was the Medium account creation. I decided to promote the game using thematic articles about game development and related stuff. Well, actually, I still do this, even with this article here :) In addition to Medium the same articles were posted to my Linkedin profile, but mostly to strengthen it. Moreover, you may find a separate topic on Libgdx website (the framework the game is written on). Then, the press release was published. Actually, you should do a press release the same day as the game launch, but I didn’t know about that back then.

And to be honest, all of the methods above were not quite successful in terms of game promotion.

So I decided to increase the game presence around the web and started to post articles on various indie-game dev related websites and forums (that's how this blog started)

Finally, here comes the list of everything created over the past month (some in Russian, be aware):

Not so many one can say. But I could not find any more good services! If you know one, please, share in comments.

What are the results you may ask? Well, I have to admit that they are terrible. I got a little less than a hundred downloads, and I’m pretty sure that most of them from the relatives and friends. And you can’t really count such as a genuine downloads, since I literally just asked them to get my game on their smartphones. But the good thing is that many of those who played Totem Spirits shared their impressions about the game. They truly liked the product! That was so pleasant to hear their thoughts. I know in person several people who finished the game with all diamonds (a.k.a stars) collected.

Still, I don’t regret the time spent on the game because I’ve learnt a great lesson — two years of development is a way too much for such simple and narrow-profile game. It seems that now is not a good time for such complicated puzzlers or I just failed badly with the promotion)

Now the next plan is to develop and launch a game in a maximum 160 hours (two working months). The coding process has already begun, so hopefully in January you will see the next product of Pudding Entertainment company!

• 71
entries
• 4
• 1198
views

#### Recent Entries

Latest Entry

Welcome to this week’s From the Forum. In this post, we highlight a few Corona Community Forums posts that cover important topics.

#### JSON for a database?

In this forum tread, the poster was curious about using JSON to hold database data. Our great community chimed in with several answers.

#### Timeout on the field!

Network requests can fail for several reasons. Timeouts are one of the errors you might encounter. This thread helps understand how Corona’s network.request() handles timeout errors.

#### Widget confusion

A new user was trying to understand how widgets worked. Forum superstar @roaminggamer jumped in to provide multiple sources and examples on how to use widgets in this thread.

Do you have a particular forum thread that was helpful for you? Let us know about it! Email support@coronalabs.com, put FTF: and the forum title in the subject, and include the URL in the email. We will consider adding it to an upcoming edition of From the Forum.

• 10
entries
• 0
• 468
views

#### Recent Entries

Latest Entry

Here's a good start at a text.txt app.  Have at it.  Written in Python and Pygame

FoolieryTextEditor.zip

• 14
entries
• 6
• 4698
views

#### Recent Entries

Latest Entry

Hey Captains

Time for another update, we have been a bit busy in all ends this few weeks, with planning of how the character customization will work and look, as well as blocking out and starting to shape out Nantucket Island.

Progress has also been very good regarding "The Pearl" and it is currently on track for the new milestone we have set.

Finally, we have also heard the call from the community and the first zone that will be playable will be called "The Myth of The White Whale", we know a lot of followers have been asking questions about Moby Dick, but as this time period wont fit, it makes a possibility for a future set of content after release.

If you know the history the book of Moby dick, it was based upon various true stories of other albino whales that ruled the sea, one of these was Mocha Dick, (together with cappuccino orca *phun*) who was a feared whale that supposedly survived over a 100 encounters with whalers in the areas around Mocha island. It is said that when he was killed, he had around 19 harpoons in him before the encounter even started.

But the myth started somewhere!

Character Customization:

Here is the old and early sketch we made to try an visualize how the character customization will look like

the style of this will be of old fine art, and you can choose hat, face and uniform in the portrait.

Sketch by Dominik Mayer

Environment, Nantucket:

Captain Zackarias, Environment Artist

Captain Zackarias made the Nantucket island and we have now started to block out and placing the assets. Nantucket is hard one, its and Island with almost no trees, and thats pretty hard to get looking good without making it feel to empty, but it is a challenge we have no problem taking on. The most important thing is to get the port looking good and making it seem busy and alive.

"The Pearl"

A 16th Century Whaling ship:

Captain Mike, Ship Builder

Captain Mike is working hard and well on "The Pearl", you might have seen some of his ships in another age of sail game, called Naval Action.

We are also opening discord for the public, where you can chat with us, give feedback, QAs, sing some shanties or listen to shantie radio!

Press the link to recieve the invite

I also want to thank everybody who voted for us during the indie awards 2017, we made it to TOP 100 and are currently the only game in upcoming realistic sim for the last vote batch. If you like what you see, we would appreciate the continuous support for the last run of votes!

Thanks again for all the support we have gotten, emails, comments and so forth, it means a lot.

With that, I wish you a Merry Christmas and an amazing new year.

Looking forward for next year and all it will bring on our front!

Cheerio,

Captain Tommy

• 1
entry
• 0
• 34
views

#### Recent Entries

Latest Entry

What went right

1. Level Design

Upon taking on the project amongst us, our first team and first game. We had no ambitions as to any level design apart from setting up our basic levels to teach the required core mechanics within the game, from movement to using our token pickups which change your Agents ‘mode’.

With the base tutorial levels, they were set up in a very efficient and simple manner, utilising core elements such as player direction and structured in a way where the players had learnt everything the mechanics could do after tutorial level, and build upon those skills while learning the other mechanics in the next levels. This was efficient, given the deadlines we had to meet and so efficient that we ended up having time to do an extra five levels all while polishing off the game at the end of development.

With our extra levels, we had each member of the team design a level each to give us all an opportunity to show of our skills and add our own flavour to the game itself. This proved to go very well, with an equal amount of work being spread out to the team and giving the game itself, more of a variety of gameplay. We have a fast paced level, a level focusing on memory, a level focused on exploration and levels more situated around specific mechanics. All in all, our level design was more than I could have ever hoped for, even if I myself would have chosen to do things differently.

2. Testing

The testing phase of our project using our prototype was done perfectly. We had a form set up on Google forms in which our team members could edit from their own devices and it was structured in a way which was not boring.

We recorded gameplay relatively easily using Camtasia Recorder (would have used OBS but, time and hardware admin privilege restraints in University facilities prevented this) and were able to go over how each player attempted to play the games or any bugs they encountered during the testing. The form and videos sometimes went against each other and having both was key to figuring out what exactly needed to be changed, added and removed.

Our testing phase dramatically changed the way we did a lot of things from some level design to asset changes.

What went wrong

1. Communication
What happened

At the start of the project, the team was more than happy to meet up once a week, sometimes on a Discord and sometimes in time after class around a table, to discuss, debate and plan out what our goals, expectations, ideas and overall what the game would turn into in the end. Our Project Manager would arrange with all of us individually/as a group and find a time available.

During our first meetings it was largely debate and hearing the different opinions on why an idea would/wouldn’t work but unfortunately, not long after it quickly moved away to a more confined area within the team.

Many of us were absent during the period near study week and around this time, we weren’t having any meetings or structure set in place. The only thing we had was a “to-do list” made by our Project Manager. It got to the point where team members were getting demotivated due to having less influence and input on the project itself and this is largely due to the lack of meetings and direction given.

Me personally, I stated near the start of the project that although I was the only experienced Artist on the team, I didn’t want to do it all it. This quickly devolved later on into some team members making sub-par quality artwork which I felt wasn’t even up to the standards of what a teenager could do in Microsoft Paint and in turn, I became upset about the direction of the art style. Expressing this was met with neutrality yet nothing was done about it.
This could have been solved if team members who wanted to do art came to discuss and maybe ask for help from myself, being the artist on the team but team members decided to just go and get work done so it is out of the way, rather than communicate and work with each other.

Suggestions of using tools such as Google Calendar were largely ignored by management.

What could have been done?

I feel like a better approach to our communication could have been taken by working out a mandatory time for all team members to meet in the next week in advance. Using a tool like Google Calendar could have let us all individually slot in the times we were available and using this, the project manager would choose a time for us.
This small addition to our cycle would not only have increased our general motivation to the project but maybe lessened our other problems with the development cycle.

A google form could have also been made by the project manager for each team member to fill out after a meeting, to give the manager an idea of people’s individual feelings they might not have had the courage to express in a group environment. This would enable the project manager to understand everyone’s perspective and adjust accordingly, to realise everyone’s potential and motivate each team member differently.

2. Team Structure
What happened?

Upon the beginning of It’s a Blob, we all decided we were going to work on multiple aspects of the games’ development as to not confine some team members to not being able to work on something they wish to learn more about, like level design or programming for instance.

Quickly, along with lack of communication, our lack of defined structure had some team members completing work which could have been more appropriate to other team members and also, left out some team members from being able to complete certain aspects of development.

Ben was a valued member of the team, who did most of the code and construction of the experience itself and Robert our manager, completed a lot of that code as well. I myself, was not interested in the coding aspect for this particular project as it is going to be something I will be able to learn from scratch during the start of my Bachelors and I ended up creating the base structure of our UI state machine, something which could have been done by another team member. It was my fault in that at the time, I said I could do it though it could have been out of the way more quickly and maybe even in a better state than it came out, if it was done by someone was wanted to do it.
The lack of structure in this case made some jobs more prolonged than they should have been.

What could have been done?

With a more set structure of what we originally decided our main roles were going to be, the project not only would have went more smoothly but had less clashes and in turn, provided more knowledge and skills to each team member.

If each team member was given a main role and if they wished, selected one or two ‘learning roles’ they wished to do, not only would each team member focused on their individual skill set they were most talented at but they could have also helped the other team members who wanted to learn more about their roles.

With this structure in mind, if someone runs out of work that week to do and wishes to do more, they can sit in with the other learner roles for other pieces of work and learn more skills while collaborating more.

This approach would be more beneficial to smaller less experienced teams though in ways, it would benefit any development team. Having these learner roles set up in bigger companies could be done once a week and could potentially decrease huge aspects of crunch time for positions which might still have a lot of work to do while other positions who have done everything required, if passionate enough to increase their skillset, have the opportunity to from experienced industry members in their own work environment.

Conclusion

Overall, our successes came from our unique perspectives being applied though our problems came from management and a lack of experience of that management. We’re all in education and not a work environment so while some of us try to do everything, some of us lose sight of what they need or want to do and that showed through the team.

Many lessons have been learnt from this project, lessons which can be used to not only better handle a smaller indie development team but to give motivation and structure to a team full of multi talented individuals. I have no doubt that twice the amount of levels achieved of ten could have been created to better explore the mechanics we created and come up with more unique game design itself within this project if our problems didn’t exist but alas, this has definitely been a learning experience for all involved and we’ve come out of this project with more experience and an idea of how to work with other people.

Development Information

Developer:   Infinity Games

Release date:   Dec 2017, PC & Mac

Development time:   12 weeks

Number of developers:   5, (4 at a later point)

Development tools:   Unity, photoshop, visual studio, monodevelop,

Budget:   \$0

• 1
entry
• 0
• 34
views

#### Recent Entries

Latest Entry

Post mortem: Infinity game’s It’s a blob

It’s a blob is a top down puzzle platformer with a cute pixel art style to the game. Currently only available on itchio.

In the game you play as the character Blob (very creative I know), Blob is part of a solitary alien race; their influence is spread over many galaxies however they are destined to spend their lives alone. But Blob is different, he doesn’t want to be alone, so it’s his goal to reunite his people.

Blob spends many of centuries (blobs live for a real long time) searching for some old alien technology that linked all his kind together. Pretty much the equivalent of Blob interdimensional Facebook and that’s where the players story begins. Blob actually found it! And now it is his mission to seek out and reunite his blobs once again.

We’re a very early indie games studio made up of students from SAE Quantm based in Brisbane, Australia. With varying backgrounds that make a well-rounded team.

Our team wanted to create a game that would be filled with the same fun and experiences as other games had been in our childhoods. Overall, we weren’t looking for any financial gain from this project but instead knowledge and experience that we could take to future projects.

What went right

1.      Ideas stage

Through brainstorming sessions and generally just bouncing ideas off each other we were able to come up with a concept fairly quickly for the project. Being able to get this information in a visual form and voting on what ideas we would use was an integral part of our process.

2.      Scope

As this project had a deadline of 12 weeks, it was very important that we didn’t over shoot with what we were capable of producing in that time period. In fact, we under shot this quite a bit. While all the mechanics were in place, the amount of levels we had to explore those were so few we had to expand them by double. This wasn’t an issue though as we had plenty of time to alter and improve on the project.

3.      Style

From the beginning we had a clear direction for the art style, wanting a fun and classic looking game, in the form of pixel art. Which was both easy to produce and visually pleasing to consume. The style remained mostly the same through out the project getting a visual tweak in the polishing stages, this was done for both visual clarity and especially if animations were involved.

4.      Testing

The game was play tested thoroughly as new mechanics were added to the game and in the final stages, which picked up on majority of our bugs and problems. We also conducted a closed group alpha testing which provide to be invaluable for our game, by recording their feedback and gameplay we were able to analyze why the game wasn’t being played as we intended.
Apart from a few in game bugs we hadn’t picked on, the main issue was giving the player to much freedom in tutorials and as a result they were not doing them or completing them in the wrong linear order which hindered their overall experience within the game.

The way we worked

This was an interesting task, being university students, we did have time in class to do some work but most of our time was apart. We assigned a project manager to the group who split tasks and generally kept a track of the work needing to be done. Although a scrum method was applied, it was a loose method. Mostly just addressing issue that arose and applying things in order as we needed it (art assets being left until later).

Meetings were held every Monday afternoon on our own discord channel for several hours, as previous work was verified, and new work was assigned from that point. Further contact was kept through a Facebook page, so we could upload and share content on a more frequent basis.

What went wrong

1.      Puzzle refinement

As mentioned in the testing section, level designs concepts that we thought were obvious as developers were not obvious to players, resulting in a poor player experience in our initial alpha testing. By changing the layout of the (portal room) and altering the intended path of the player (forcing them to complete levels in a certain order) we were able to fix this. However, it required more time and effort than was necessary than if we considered this at an early stage.

This was a big one, while we had an idea what we wanted and incorporated that into the game this changed throughout the project, with new ideas being tested and trialed on the fly. Sometimes working and sometimes causing more issues. These included:

·         Changing camera perspective through game development (many hours changing and recoding)

·         Changing level design

·         Recoding the interactions between player and objects

·         Change of assets

·         UI

However, the results of this undeniably improved our game, but by planning ahead and coming up with a conclusive design, we could have mitigated these risks and saved ourselves a lot of time.

3.      Management
This was something that was a bit all over the place, initially task were delegated as they were needed to the people appropriate... great, however as the project went on and the focus was more on coding, tasks were being split unnecessarily for the sake of feeling included in that point in time. This resulted in a mess of trying to collaborate work, double ups of some work and sometimes things just not being done at all. In the end it reverted to the old method of only being given to the appropriate people.
Some delegated tasks were not being completed as well, forcing others to pick up slack to make sure the project was on time.

Conclusion
Overall this was a great experience for us as early developers, even though it had its ups and downs. It gave us an insight into many of the aspects of both team work and the development of a game. We learned a lot through out the process too and im sure we will all be taking these lessons on to future projects. It’s a blob was never meant to be anything more than an educational project but to me it become so much more than that. I’m proud of it

Development stats

·        Developer: Infinity Games

·        Release date: Dec 2017, PC & Mac

·        Length of development: 12 weeks

·        Number of developers: 5, (4 at a later point)

·        Development tools: Unity, photoshop, visual studio, monodevelop,

·        Budget: N/A

·        Sleepless nights: 2

• 4
entries
• 0
• 84
views

#### Recent Entries

Latest Entry

Check out a couple of things I leaned from Reinvent 2017!

# AWS Cognito

## Long Version in a sexy voice

• 16
entries
• 4
• 435
views

#### Recent Entries

Latest Entry

One of the most important aspects in a shoot ’em up is certainly score. Being somewhat a niche of a genre, it has a clear competitive edge among its players. It certainly lacks fulfillment in terms of engaging story, but the adrenaline rush in combination with the goal of attaining higher and higher scores or even being on the top of the leaderboard is something really hard to beat and is specific to the genre.

With that in mind, a good shmup scoring system has to be easy to understand and engaging at the same time. While it sounds simple, it can be quite hard to achieve a good “funness” factor while keeping it engaging and skill related.

For Rick Henderson and the Artifact of Gods, i dissected a ton of old and new shoot ’em ups in the search for the perfect scoring system i like. One of my all time favorites is certainly Galaga Deluxe (or Warblade for PC folks) for Amiga 500 from late Mr. Edgar M. Vigdal. Besides coins used for shop purchases (which this game won’t be using until singeplayer mode is done), in Galaga you can collect gems too. Those little cuties come in different shapes and colors and each one yields a different amount of points. While not groundbreaking, it adds another layer of depth to the game besides dodging as some gems are really worth running for through a rain of bullets. Naturally, tougher enemies have higher percentage of dropping rarer gems that yield higher score addition.

Another form of bonuses that can be picked up are medals. Far from my knowledge, medaling is prominent in shoot ’em ups. The concept is easy: you pick up differently colored medals, when you have the whole set, you get awarded a rank at the end of the level and the medal collection is resetted when you start the next level. You guessed it, ranks are just another name for total bonus multiplier at the end of the game.

There is a total of 9 ranks you can attain (the first being the multiplier of 1, which is your default rank):

Recruit
Private
Corporal
Sergeant
Lieutenant
Captain
Major
Colonel
Marshal
Commander

Complete randomness in spawning those can be infuriating for players with higher skill cap, but i find it refreshing to have a bit of a variety and a possibility for the medals already collected to appear again. Below you can find a weight distribution chart for the medals. When none are collected, the chance for any to spawn is equal. However, as the number of collected medals increases, the chance for already collected medals to appear diminish by 1/5 (or 20% if you like it that way). I haven’t done the exact maths, but the chance for already collected medals to appear is not that large. Of course, for collecting already collected medals, you get a nice, juicy score bonus, so they are worth catching too!

Multi kill bonuses! We all played Unreal Tournament 2004 back in the day. It had a nice feature of multikills which i use in my game in a bit different form. For those who haven’t played it, you get multikill for killing two enemies in a row without dying. As your kill count progresses (again, without dying) you get megakill, ultra kill and so on. In Rick Henderson and the Artifact of Gods it functions based on time between two kills. When you kill an enemy, an invisible timer starts counting down. If you manage to kill another enemy until the counter hits 0, you get double kill and the timer resets. If you manage to get another one until timer counts down, you get a multi kill, all the way to monster kill. Of course, every additional kill is awared with more and more points. This is usually possible with area of effect weapons (explosive ones) and weapons like Railgun, which can go through multiple enemies, encouraging player to invest more skill in the game.

Grazing bonus is usually omnipresent in bullet hells, a hardcore subgenre of shmups. It encourages the player to “graze” bullets, ie. pass very close to them without getting hit.

Design itself was a bit harder to implement since it involves tracking multiple bullets at a time getting into the graze range and checking whether they hit the player or not.

While not neccessary for the gameplay since i don’t want it to be bullet hell, it’s one of those things setting apart rookies from hardcore players that want to get the most out the game.

And finally, the good old bonus multiplier which adds up with every destroyed enemy, gets lowered when you get hit, and reset at every waves end. It goes well in combination with grazing bonus, making you get closer to the bullets but not get hit. It also serves as a kind of damage control system. Since i gave up on the idea of having a 0-100 healh bar and chose a 10 life bar instead, hits from tougher enemies take more of your bonus multiplier down.

I believe the score mechanics are very easy to understand and will add up much to the investment of the player and the adrenaline pumping of the true genre players.

The post Scoring System Design appeared first on Fat Pug Studio.

• 14
entries
• 15
• 2708
views

#### Recent Entries

Latest Entry

Dreamart VR is the direct interpretation of a dreamworld. The player resonates with the mere subconscious thoughts of the virtual character.

The game consists of multiple scenes. Each Scene is directly or indirectly correlated to the previous scene, thus it unfolds the potential of a deep non linear VR experience.

E.N.J.O.Y

• 3
entries
• 0
• 287
views

#### Recent Entries

Latest Entry

Hi, there!

Work on TERRORHYTHM is in full swing. Over the past week, we have managed to develop and add animation to the main character and the enemy. We also tweaked the location environment. Check out the difference between before and now.

• 25
entries
• 53
• 17188
views

#### Recent Entries

Latest Entry

Let's get back to the creating an app package and uploading part, as that is where I experienced some difficulties.

I had an locally working Universal Windows Platform game, a Microsoft account and Visual Studio Community 2015.

So per instructions you'd right click on your app in Solution Explorer, choose "Store->Create App Packages".  Sounds easy, but didn't work. A dialog came up and showed an error about not being able to connect to my account and Visual Studio actually hung.
I had no idea why that part wouldn't work. Restarted Visual Studio, updated the SDK, rebooted, nothing changed. Than, after reading that dialog more focused, it dawned to me. A plain Microsoft account does not suffice, you need an actual developer account. This is two different things!

So off on developer.microsoft.com I created an account, paid the required license fee (something akin to 9 Euros) and voila, the dialog would suddenly work!

From here on I created the App Packages, which required a few more settings to enter. Here's another stumbling block I encountered: You need to provide a few logos/badges/icons. All in a gazillion formats, scaled 100% and 200%. Here I wish you could provide one image and have the other formats auto-created. From there you could still polish up or replace the uglier ones. If you ever want to modify the settings of your app either double click "Package.appxmanifest" or via menu Project->Store->Edit App Manifest"

Finally my app packages compiled successfully (per default you'll have x86, x64 and ARM). Then came the Application Verifier...

The Application verifier will run your app several times, check your icons/badges and after a few minutes return a result of either "failed" or "passed". The link behind that will show you the details why something failed. The listed errors are also linked to a web site explaining the messages in detail.
For example one of my failures was explained as "The first pixel of the icon is not 0xffffffff or some other value)". What that message actually means: Those particular icons are supposed to be two colors only. You'd expect that to be shown when you select that image in the app properties.

• 36
entries
• 7
• 4044
views

#### Recent Entries

Latest Entry

Hi again everyone!

Today I’m writing a small devlog just to let you know that FAXIME has entered Reddit Gifts Secret Santa and we’ve already received our present! We asked for something for our office and we got a a mat ahah it’s really cute, I’ll leave a picture down below!

We've thanked on reddit and our Santa reveled herself muahahah.

Basically everyone who knocks at our door smiles :).

And we’ll also be at Comic Con Portugal this saturday! Swing by IPCA’s stand if you’re over here in Portugal!

On the holiday spirit Happy Hanukkah for the ones who celebrate it!

Fun fact: In Portugal we eat more sufganiyan during the summer!

[Image made by our team member Lidar]

See you soon….

The FAXIME Team

Follow us and keep updated at:

Instagram: https://www.instagram.com/faximegames
Pintrest: https://www.pinterest.pt/faximegames

SoundCloud: https://soundcloud.com/faximegames

• 27
entries
• 62
• 24996
views

#### Recent Entries

Latest Entry

Originally posted on FidelumGames.WordPress.com

In my last post, I said that I hoped my blog posts would start getting more frequent. That was over a month ago  😐

But that doesn’t mean I haven’t been working on things, I just don’t have anything new that’s super interesting and warrants a blog post.

However, I really want to make these posts frequent and keep everyone who’s interested up to date on what’s going on with the game’s development. Because of this, I’ve decided that between meaty, interesting posts, I’ll simply post each of my version control commit comments as I make them.

I figure this will keep the posts coming, give you all a sense of what I’m working on and what I’ll be working on next, and provide some insights into the minutia that come along with game development.

I set the current repository up fairly recently, so there aren’t a ton of commits as of yet, but here is a dump of  all of the currently existing comments:

8/29/2017 4:06 PM – Initial Wayfarer project commit

10/23/2017 5:08 PM – Milestone #1 Commit – Stable, first feature set complete.

11/4/2017 9:29 PM – Updated GDD with Overview and Implementation algo for player combat (attacking and spellcasting).

11/9/2017 11:24 PM – Added basic player attacking functionality, as well as initial defense and dodge calculations. Player’s EndTurn, when striking an enemy, is now called by the enemy being hit after its animation is done playing. The next step is to do the same for when the enemy strikes the player. Noticed two bugs: Player gets his turn back too often, and the enemy calls TakeDamage on itself when casting a spell on itself which inflicts damage (Blood Magick). Need to figure out why the player is able to act so frequently, and change how self-injuring spells subtract health from the caster (another function, or maybe a flag to the existing function). These two issues are probably related.

11/11/2017 11:38 PM – Fixed bug where player could attack too frequently. Also modified Stats.TakeDamage to have an optional paramter shouldPlayTakeDamageAnimation (or something like that) in order to prevent self-damaging spells (blood magick) from triggering the take damage animation.

11/14/2017 1:29 PM – Basic functionality for both player attacking and spellcasting is complete. Still have to add some tweaks for reactive animations and turn ending when an actor is hit by a spell.

11/15/2017 12:13 AM – Added target effects for spells which have an immediate effect. Added additional EndTurn triggers to handle these. From what I’ve tested so far, all cases where the player attacks or casts a spell on an enemy work as expected.
Next thing that needs to happen is enemy death. The dissolve assets have been brought back into the project, and just need to be called when the enemy dies.
After that, adding reactive animations for the player when a spell is cast on him, or when he is attacked (dodge, get hit, etc.), and ensuring those reactive animations trigger EndTurn in the correct Enemy. This will probably be in TakeDamage(since it has a reference to the Stats of the attacker anyway).

11/16/2017 11:20 PM – Death animation now triggers dissolving. Found a bug where an enemy gets an extra turn when taking damage. Dying doesn’t occur as expected. Fix this.

11/20/2017 10:08 PM – Fixed some problems with turns ending at the incorrect times/too many times caused by some poor logic in SpellManager. How spells work and the exact point at when they have their effects applied, as well as when turns are ended has been more tightly defined. All callbacks from animation events triggered by spells or attacks targetting the enemy are working as expected, with the exception of Healing spells. This is because of the current AnyState->AnyState transitions used in the animation controllers and the close proximity of the Heal Casting animation and the Get Healed animations being triggered. The state instead transitions right from Heal Casting back to Idle. Because of this, the animation state machine will have to be more properly arranged.

Once this is done, callbacks for when the player is the target of spells need to be added (none are done). Also, these animations will have to be set up for the player (mostly utilizing iTween).

Even though all of the spell stuff is mostly working well, it just doesn’t feel right, and is a likely candidate for redesign later.

11/21/2017 10:15 PM – It seems that all callbacks for both the enemy and player are complete for all permutations of both self inflicted and opponent inflicted effects (Damage, healing, status effects, etc). This also takes into account and plays the appropriate animation for affinity to magick types (having greater than 100% fire defense will heal instead of hurt the attackee when a fire spell is cast against them). Of course, all graphics, vfx, and animations are currently placeholder, but it seems that the code is solid and complete.

In order to accomplish this, the enemy animator has been totally revamped.

Still have to test more thoroughly (with multiple enemies, additional spells, active combat mode, etc.)

Have to perform clean up on some unused animation boolean sets in code.

11/22/2017 10:01 PM – Milestone#2 complete! Player actions are working perfectly and complete combat cycles are able to be completed with either the player or enemy being defeated. Player is able to attack and cast all spells, although no mechanism to change equipped spells or weapons currently exists (except for through the editor [weapons cannot be changed at all]). One small bug still exists where the Enemy is able to cast some ranged spells when not in line of sight of the player. It seems only range is being taken into account. This should be an easy fix, and not something I’m currently worried about. One small fix was made to a bug where the player would become misaligned with the grid if attempting to move while a player animation was being played (dodge, damage, taunt).

Tests with multiple enemies were successful as well.

Need to decide what Milestone#3 will be: UI Design seems like the most reasonable candidate, as this will lay the style and determine the framework for most of the systems to come (inventory and player management, including weapon/equipment management and equipping, spell selection, and levelling up as well as all other core gameplay areas including dialog, quests and pretty much everything else to come).

## Paralysis by Analysis

Things have been moving slowly lately.

The game is at the point in its development where things really can’t progress until some UI has been put into place.

The player is able to both attack and use spells, but there is no in-game mechanism by which to switch spells or weapons (the spell system, as I’ve mentioned before is done, but the placeholder weapon is purely superficial; it doesn’t affect stats or combat at all.).

Because the AI and base player combat mechanics are complete, it seems the best thing to start next is looting and inventory management. This will range everywhere from the player looting enemy bodies (or bags dropped–not sure how I’ll handle it yet), to changing equipment, spells, etc.

I could write the back-end for this stuff, and just switch things out in the editor for testing, but it seems the best way to progress is to at least have some idea of what my UI will look like and how it will function so that I can best design the code.

This is where I’ve been having difficulty.

The only other game I’ve completed to date was a single screen 2D shooter called ‘Pixel Zombie Shooter’ (you can play it on Newgrounds), and it had a pretty minimal/simple UI.

Needless to say, I have little experience when it comes to UI design, and I’ve been struggling to figure out what would best suit The Wayfarer.

So far, I’ve completed a ‘mock up’ of the main game’s UI (the one the player sees during combat and exploration). Have a look:

Before I get into my major complaints and problems with this mock up, I’ll explain what you’re looking at first.

The items along the bottom (red and blue orb, bottom-most panel buttons and two circular buttons to the right) are always present.

The panel containing the potions slides up from the bottom when the red portion of the orb is clicked and held, or when it’s right clicked. It’s intended to be a quick access menu showing only items that will heal the player.

A similar panel would appear containing mana-restoring items, equippable weapons, and spells when the blue portion of the orb, the sword or the fireball looking button are clicked and held or right-clicked, respectively.

Basically, I wanted to give the player automatically filled quick-access buttons for commonly used items (health and mana items in particular), as well as a quick way to change spells and weapons.

I think this is a pretty good design functionally, and would help alleviate some of the pain of navigating through tons of menus that is so commonly associated with RPGs, but I’m not sure if I’ll stick with it or not–simply because I think it’s a bit of an unconventional and nontraditional design that might not be intuitive enough for players. (Psst: I’d love to hear some feedback.)

On top of having the ability to display these quick-access menus, left-clicking on the red orb would automatically use the healing item best suited to the player’s current health (healing as much as possible without wasting the item’s healing potential). The same thing would occur with the blue orb, but for mana.

The sword and spell icon would simply attack with the current weapon, or cast the most recent spell, accordingly.

The icons along the bottom, from left to right, would allow the player to:

• Access their inventory
• Access their character Screen
• Access the map
• Access spells
• Access quests
• Rest

Of course, each of these functionalities will also be able to be performed with shortcut keys (‘I’ for Inventory, ‘R’ for Rest, etc.). In the end, nine of these eleven buttons (all but the health and mana buttons) are ultimately redundant because their functionality will be duplicated with key presses. However, I think the benefit of intuitively letting the player know the functionality exists by showing it up front and center probably warrants their presence. Again–we’ll see.

Now for the problems I have with this so-called ‘mock-up’ (perhaps a mockery of a mock-up is a better description).

First of all–just look at it. While it’s not perfect in its appearance, it looks pretty damn close to a polished UI. The problem with that is that it’s a mock up. It’s not supposed to look polished.

While I did do some pencil and paper experiments first, I think I spent too much time making it look good, and I think that’s a bad thing–at least for this stage of development.

I should be focusing on layout and functionality, not final appearance (although that’s probably a good thing to keep in mind while designing).

While the mock up you see above only took me a couple of hours total to put together, it caused complete paralysis when it came time to design my next UI (specifically my character equipment screen).

I started drawing stuff on paper, then went on to photoshopping, but ultimately wound up with nothing.

My mind was too all over the place.

Something like this went through my mind:

Quote

Do I want a diablo-esque equipment screen? No. That’s a top-down game–does that really fit for me? What about a more abstract equipped item scheme using ‘isEquipped’ markers like in ‘The Quest’?

Should the equipment screen always have the inventory screen attached? Or should it always have the character stats screen attached? Or both? Or none?

Should my menus be tabbed, allowing the player to click through the menus, or should they be independent floating windows? Do I want a full-screen menu system, or windows?

Jeez, I don’t know. It really depends on how the game plays and X, Y or Z. I don’t know X, Y or Z yet.

Although I have a pretty solid overall vision for the game’s theme, look and feel, there are still a ton of unknowns. It was at this point that I fully realized that really, I’m still prototyping.

Rather than trying to make all of these decisions during design, I need to be doing some bare bones experimentation to see what works and what doesn’t in order to make my decision making part of the design process.

So, rather than developing further semi-polished mock ups like the one I’ve already made, I need to have some super basic black and white boxes with text instead of images for buttons, etc.

I need to be rapidly prototyping, testing, scrapping and refining these UI menus directly in the game (maybe some quick pencil and paper first). I think I need to make a UI for each of the questions I’ve been asking myself and actually trying it out, instead of just trying to imagine the pros and cons of each. I need to test each one (and hopefully, get some others to test them too).

Ultimately, even if I’m not able to make some final UI decisions right now, I don’t think it’s a big deal. I just need to get something relatively close to what will work best so I can move forward with developing future mechanics.

There will be lots of time to revamp the UI later if I need to.

That’s it for now, and please, if you have any feedback or critiques, share them!

• 1
entry
• 0
• 61
views

#### Recent Entries

Latest Entry

Service Pack 1 include [ http://store.steampowered.com/app/718840/DiamondFalls/ ]:

- Improved performance;

- Fixed small bugs;

• 503
entries
• 1888
• 333780
views

#### Recent Entries

Latest Entry

In part 1, I wrote about a difficulty endemic to just about any porting project,
the importing and trans-coding of data to different formats.

Here in part 2 I'll cover a few of the trickier engine architectural differences that exist between
the original engine for Static:IT (Selenite) and the new engine that will support it (base-code from 96Mill and Revel Immortal)

Different Origins

Originally designed to support editor-only development of Adventure and RPG games,  Selenite
was a successor of the S3Engine (The Lost City of Malathedra); and shared many simularities
with the primary exception being that S3 was designed such that scripts and associated resources
were to be written in external tools, and the S3Engine was a pre-compiled exe run-time, that read and
executed the scripts and resources.

Selenite on the other hand, was an IDE, where game objects were added via a tree-view interface, along
with resources; and the IDE was responsible for processing and packaging these resources for optimal end-use.
The resulting resources were likewise run next to a pre-compiled SeleniteWin32.exe

There is a relatively large expanse of time between the creation of Selenite in 2009, and the creation of Engine4
(or EngineIV ...it's not really important) in 2013; E4 represents several massive shifts in the way I build engines
at least as of the time of this writing.

• It's in HTML5/JS, runs in the browser, and is 'wrapped' for platforms/services that only except exe, etc.
• It's heavily designed around The Trinity Pattern which is a design pattern I developed to aid in making a game
expandable, without breaking save-games, or amassing technical-debt with each release.
• Dependency Injection and Law of Demeter are used heavily to reduce coupling
• It's a series of engines, where for each new game we clone the engine code of a game most like it;
and features are selectively merged backwards if they're desired.
• Each game's run-time is optimized to that game, without regard for other games. This is to avoid
having to square new features or feature modifications/removals against existing games.

The Problems

It became clear early in the port, that I was going to have an issue with the difference each engine handles
a concept which I refer to as residency.

In Selenite, there is the the Game class, which has a list of Room classes, and each of these rooms had a list of Actor classes;
and when the game was loaded, that tree structure would be created and resident in memory; addressable at all times.

...not a terrible design, but one I had departed from a while ago; the primary issue is that Selenite mixes the issue of State
and Runtime ...that is, objects are in charge of their runtime representation, mechanics and non-persistent state and
they also hold their persistent (save game) state as well.

In Engine4, the there is a separate class for a game object's persistent state, as well as its runtime.

This allows an object's state to be retrieved, and passed into the construction of a newly minted runtime object.
runtime objects can be created and destroyed at will, with its separate persistent state living on.

This explicit separation of persistent state, as well as the tear-down and reconstruction of game objects

...however!  That is really not important in the context of porting Static:IT

So, the residency scheme in Engine4 (well new Static:IT's copy of it at least) needed to go, it simply wasn't worth
trying to massage the wealth of code to deal with alternate mechanisms for modifying non-resident runtime state
when I could bring the engine into alignment with the original needs.

...and thankfully, due to dependency injection and law of Demeter; the change was easy.

Instead of creating and destroying each room, and its actors as the player traversed them, I was able
to shift the code, changing mostly top-level factory functions, to create and maintain the total list of rooms
and actors at start.

...in Part:3 I'll cover issues pertaining with porting the scripting from Lua to JS

• 8
entries
• 37
• 7706
views

#### Recent Entries

Latest Entry

This challenge was a good run because of

• Implementing coroutine with IEnumerator and yield return
• Simple Dictionary based texture manager
• Basic Particle Engine
• Ripped GameStateMachine from previous monogame project (joust)
• had fun making flare particles
• Did I mention, it's not cool unless it has lightning bolts
• browsed current scifi google images...nice...inspired.

Source : MarkK_LightningCommand.zip

• 0
entries
• 0
• 75
views

No blog entries yet

• 0
entries
• 0
• 71
views

No blog entries yet

• 116
entries
• 119
• 104895
views

#### Recent Entries

Latest Entry

Hello.

I am working on a big spaceship for the game. It is in an early stage but the main shape is here. The rear part is even less detailed than the rest. There will be the reactors and some "cargo" in the large empty space under the "wings".

• 1
entry
• 0
• 75
views

#### Recent Entries

Latest Entry

Here is a small realisation I just finished. It is small, 7x7x7 cm. It is made of polystyrene, cardboard, wire, cotton wool, glue, saw dust, paint and a little bit of salt.

• 5
entries
• 0
• 110
views

#### Recent Entries

Latest Entry

The design team initially proposed that we use the spaceship as the central HUB world for the player to return to after a mission’s closure, with this decision unanimous, we began to work chronologically into the game. On the contrary to regular practice and due to inexperience, we began working on the players introduction to the game and tutorial first, before turning our attention to the roguelike elements required, as per the brief.

Much of the design work that the team and I worked on was based around the level design of the HUB world and the narrative that could be construed through onboarding. Due to the focus in this area, the main game suffered inattention.

Systematically speaking, once the scripts were working in the HUB world, they were supposed to translate smoothly into the level generation there after. Unfortunately this did not go as planned and by the time our attentions had turned to the procedural generation, serious system issues began to highlight themselves. I believe that if we had have worked solely on the procedural generation first to meet the brief requirements and then worked backwards, creating the HUB world then the tutorial, we would have a product that is much more compatible with the brief. As I venture into other projects, this lesson learned in prioritising, I feel is the most important one that I will carry with me to ensure this issue is not repeated in future endeavors.

• 1
entry
• 1
comment
• 66
views

#### Recent Entries

Latest Entry

Up to now, I have had a tendency toward monolithic classes when developing in Unity. My experience has always been with the typical object-oriented approach (with the exception of when I was developing using batari Basic), but I’ve been trying to train myself toward small, reusable components with focused purposes. I’ve had some good success lately, breaking larger scripts into smaller ones and using interfaces as a means of communicating between components where possible.

public class ReportAttack : MonoBehaviour, IDamageable {
public Team team;
void Start () {
team = GetComponent<Team>();
}

void IDamageable.TakeDamage(MonoBehaviour from, DamageType type, float amount)
{
var attackerTeam = from.GetComponent<Team>();
if (team && attackerTeam && team.team != attackerTeam.team)
Debug.Log(gameObject.name + " says: I've Been Attacked by " + from.gameObject + " on team " + (attackerTeam ? attackerTeam.team.ToString() : "no team") + " with " + System.Enum.GetName(typeof(DamageType), (DamageType)((int)type << 1)) + " (" + (int)type + ")");
}
}

While I’ve been fairly satisfied with the use of interfaces for calls to multiple or unknown components, I recall fondly the rapid development and flexible approach provided by utilizing messages in my 2017 Global Game Jam submission, Metalmancer.

However, since Unity’s message passing uses reflection (or at least probably does, given that it takes the string name of the event to call), it does not perform particularly well. With that in mind, I hoped to make my own, alternative messaging system which is used much like the existing messaging system, but uses delegates and event handlers under the hood. This was the result.

While I felt that I succeeded in my goal of providing a useful interface that hid the reflection-based old messaging system, I was crestfallen once I began running tests. On average, I see a performance increase of about 33% over Unity’s built in SendMessage, with the complication that all components using the new system must inherit from the new MessagingBehavior abstract class, rather than directly from MonoBehavior. Still, given that a direct call (as would be the case using an interface) is still about ten times faster, I wasn’t particularly encouraged by these results.

On the other hand, as tomvds said in the Unity forums:

Optimization is not about avoiding expensive code. It’s about avoiding expensive code where it matters.

Still, stubborn as I am, it’ll be hard to convince myself to use even my own message passing architecture in lieu of more efficient interfaces. Or maybe I should just use an adaptation of wmiller’s Events system. Or I should just stop worrying about it.

• 1
entry
• 2
• 86
views

#### Recent Entries

Latest Entry

(you can find the original article here)

You've done it. You made the jump. You've gone from "just working on a project," to identifying yourself as a real-life game designer. You've got a solid game design document, a (mostly) working prototype, and have even started to deal with the incredulous looks of bewilderment and disbelief when you tell people you're "making a game".

As you consider your wild fantasy of a design, the gravity of what you've signed yourself up for BEGINS TO DAWN ON YOU:

"What have am I doing?" "Is this even possible?" "Am I crazy?"

These are among the frantic questions that race around your mind. Every time you find yourself thinking about letting your hopes of making your game die, you remember: You are a game designer, and this game deserves to exist.

I put together this list to share how I've coped with the affliction of being a game designer. As Renaissance Man Kanye West put it, "this shit was hard to do, man!". Everyone has a unique environment, circumstance, and perspective when it comes to creating art--video games are no different.

Even though these suggestions won't work for everyone, I've tried to think of things that can apply to every indie designer, regardless of who they are and what game they are designing. You should also know that I've broken every one of these rules at some point during development myself. So, don't beat yourself up -- with these suggestions, starting late is much better than never!

## 1) Keep going

It seems insurmountable.

First, there's thinking of a way to craft your game that doesn't feel the same as everything else in the genre. That's before coding billions of mirco-conductors to manifest the wild fantasy of you've envisioned.

After that, you have to make sure it's good--even something as simple as moving a character around a 2D plane may need dozens of iterations to be balanced properly. As a designer, you don't ship with your game. Early in the process, you have to consider if the player can actually figure out what they're doing without you hawking over their shoulder. This issue is addressed through the use of designer-player communication tools like the GUI, prompts, and message windows.

The fact is, as an indie designer there will always be a million things to do. A lot of times at least half of them are going to seem impossible. A great game design professor once told my class that the "design never ends," despite the fact that the game has to ship at some point. What defines an indie game designer is the willingness to face these odds through failure, disappointment, and ridicule.

Just remember: keep going! In my experience, indie development works great in combination with "tunnel vision," or the ability to ignore and look past distractions and other exterior actors and concentrate on the goal or task at hand. Remember why you chose to do what you do in the first place. Remember how you've already come as far as you have, and consider why the world needs your game.

## 2) Make lists

During my university career, I was once told that "humans are monkey-minded". The notion has stuck with me. I remember the lecturer explaining how our mind naturally skips from thoughts, to memories, images, and everything in-between. A primary role of our self-conscious is in mediating and ordering this "monkey-mind" so that we can do things like have conversations and file our taxes.

Not to too get super Dalai-Lama here, but both creativity and the path to a state of peace and contentment are empowered by giving freedom to the monkey-mind. Of course, there are times where the monkey really should be paying attention, but even if you have to wrangle it in, it's only kind to be gentle, right?

To get to the point--lists are a great way of allowing yourself to be creative. And remember, the lists don't have to be exhaustive--you can always make another one! Make a list for your tasks for the next month, the next day, the next build, or the current character you're making.

As I stated before, there's a lot going on when you are developing games--especially on a small team or by yourself. It creates a lot of baggage -- you can be constantly trying to recall details of bugs you need to fix, or details of an art asset that needs to be changed. Committing the things you need to do to paper allows you to release those thoughts so that they don't have to take up space in your mind. That way you've got much more room for your monkey to wander and gather the fruits of creativity!

Also, give yourself the satisfaction of checking, crossing off, making a blood oath, or whatever it is you want to do to the list to communicate to yourself that a task is done. No matter how big or small of a task, use it as an opportunity to celebrate. It was on list, and now it's done. You fucking did it! You are a little bit closer to bringing your game into reality.

## 3) Take breaks

Remember the "fun meter" from the Sims? It's a real thing! Respect your fun meter.

Sometimes that might mean giving yourself a night off to decompress after banging your head against a wall for hours trying to fix that collision bug--maybe by switching to something like writing blog posts or by watching "Indie Game: The Movie" or an episode of Double-Fine Adventure. Do what you can to get yourself back into the zone. If you can work in a positive state of mind, both your work and efficiency will benefit as a result!

Good games take sacrifices of relationships, money, and perhaps most importantly--your time! So make sure you are managing your energy and putting some time into maintaining your physical and mental well-being. After all, if you're unwell it's harder to make a game!

## 4) Use Naming Conventions

Anyone who’s been hundreds of files deep into development and managed to lose that crucial asset that they've worked on for hours will stress how important this point is.

Proper use of naming conventions will save you a world of time and frustration. Your method doesn’t have to be too elaborate as far as “professional” conventions" go, but your main considerations should be consistency, clarity, and convenience. Whatever system you decide to use, make sure it’s logical and predictive for you. If someone else were to make an asset for your game using your naming conventions, you should be able to tell what kind of asset it is in your game, and where it belongs.

It can be very simple, but must be enough to make your assets distinguishable. It’s also important to carry this relationship with naming conventions across your whole project! For me, this includes art assets, scripts, and even the images I use for blogging. They might change from subject to subject, but the main thing is to make sure you know, and understand it, while finding your system efficient.

## 5) Talk to people

Developing Class Rules has been one of the most isolating experiences of my life. Making a game is itself a profession that is already at odds with society's "norms" and expectations of what constitutes wage labour and otherwise normative ways of life. Further, the actual day-to-day process of developing games is alien to the vast majority of people. Attempting to explain the minutia of "the awesome new script" you're working on, current hiccups in the coding process, or the labours of trying to balance a level often results in a glazed expression of confusion and apathy.

But, it's not their fault! What did you expect? You're a game developer! How long have you listened to the minor details of what other people do during their day at work? And really, why should you care so much? There is no way to know everything, and most people will not have the tools or to communicate with you about the in-depth details of your work.

The point I'm trying to make is: don't let game development's complexity discourage you from trying to talk to people about your game. Yes, a lot times you'll get friends and loved ones putting you down, disbelief in game mechanics you think are awesome, Han Solo shaking his head, and blunt disinterest in what you dedicate much of your time to. But at the same time, you can be faced with the exact opposite: great new ideas spawned from situations and conversations , songs to listen to, movies to watch, renewed fervour and faith in your project, or in short -- creativity.

Take criticism as an opportunity to review your reasons for doing what you do the way do. Take yourself through the uncomfortable process of challenging your assumptions. Make the reasons why your target market deserves your game evident within your work.

Setting deadlines is huge! It's a little related to making lists, but I think it deserves some more attention. When working by/for yourself it becomes very easy to let things slide. Pressure -- even if it's completely of your own fabrication -- is a great motivator. But, be realistic when setting deadlines for your schedule. This is especially true for the pre-design and prototyping phases of the project. In my experience, development times start to become a little more predictable as you become more attuned to the specific systems of producing parts of your game.

Deadlines can be set for a lot of reasons -- contest or festival entries, grant submissions, presentations, and your aunt's wedding are all valid reasons to make a stable build for your game. This is also something you can at the end of every week or two weeks to make sure you have a current and accessible version of the game ready to go just in case.

Take the opportunities that you can to show your game to your peers and public. I think the most important thing going into any environment where you will have the chance to playtest and learn about your game is to know what it is you hope to answer during the playtest. Watch how your new section plays, or how players react to the dialogue. Try to have an idea of what you want to learn and take away from the play test! That way you can optimize the structure the session to get the most out of the feedback.

## 8) Make it count

Game design is an art. Your work has meaning. The power that the messages behind your game can mean for other people should not be underestimated. You have the opportunity to do something that matters for others, so do it!

I touched on the importance of making the effort to consider why your game deserves to exist earlier in this piece. Ask yourself why your game deserves to be made. Perhaps more importantly, why does it matter? As a designer, I think you should be repeatedly asking yourself these questions throughout the entire development process.

In 1809 when Napoleon led his armies to victory over the Prussians in Jena, German philosopher Georg Wilhelm Frederick Hegel claimed it was the "end of history". It ensured that the ideal "liberté, égalité, fraternité" would be pursued by all peoples of the world. The marriage between Napoleon's actions, and Hegel's thoughts are an example of a powerful dialectic representing the real political action that comes as part of some great artistic or literary works.

Videogames, as with all other forms of art, can be used as an agent of political change. If your game contributes to a message, or was designed to communicate something about a particular topic, you will have a much easier time motivating yourself to see your project through. And as indie, aren't you here to make unique games that wouldn't be considered by AAA studios anyways?