Here’s what I’ve accomplished this week.

+ Persistent data storage
+ Basic Experience Point and Levelling mechanics

Data Persistence

Data persistence is an important part of most, if not all, games. My games up until now have been very basic with the only persistent data required being a level number, and points value to continue from. NSUserDefaults, whilst not intended for this, has been more than adequate.

The development of Coffee Cellar lead me into the murky world of Core Data. Core Data abstracts the data models from the storage method. I ended up using it in conjunction with SQLite3 and it worked quite nicely (Especially since I had relationships between coffees, tasting notes, etc).

For this game I decided to ask my peer group on twitter and got a decent number of opinions. Suggested solutions included plist’s, the NSCoding protocol, and JSON. These solutions all have their pro’s and cons.

The data I want to persist in this game is…

• The players character level, experience points, and class.
• The inventory – quantities of each tile and amount of “gold” (This is complicated slightly by the crafting system)
• Quest Data – completed quests and quests in progress
• The levels that have been completed

Its not a trivial amount of data but neither is it absolutely huge (something you can’t know without knowing the underlying solutions for each of those concepts). The solution I’ve opted for is a single plist (Property List). A plist can only contain a small number of data types but they are more than sufficient for my needs and they tie in well to the solutions for the systems mentioned above. I also use a plist for all of my level data (its the output from my level editor).

There are a couple of downsides to using a plist. All of the data is loaded into memory – this isn’t a problem for the persistent data because I know its maximum size up front (and its not storing huge amounts of data). The levels are another matter and I may end up splitting them into individual plist’s – I’ll run performance tests to make that decision.

The other issue is that a plist is not obfuscated in any way so, should someone wish, they have easy access to the data (and therefore easy access to modify it).

That last point is really a non-issue for me right now. This game does not have a competitive element to it (I’m not planning on leaderboards). I figure I can use a slightly different concept for score data if I do ever feel the desire to incorporate some form of leaderboard.

So, for now, its a singleton writing to, and reading from, a single plist.

Character Levelling

PPRPG is going to have the concept of levelling-up your character. I wan’t to keep it simple so that its totally transparent to the user as to why they gained a level. I also want to ensure that the complexity fits with the iPhone as a gaming device (i.e. people playing on the go).

You’re character will not have any attributes other than experience points. No health, stamina, strength, charisma, and what not – they’re too complicated for a game that you play when you have a few moments to spare. That’s not to say the game won’t have depth (I just don’t want statistical depth).

(This image is just to show you the concept. It won’t be this ugly in the finished game.)

So, you’ll start off as a level 1 character with 0 experience points.

You’ll be show how many experience points you need for the next level. This is currently calculated as ((current character level * 200) + 50). Adding a static value to the simple multiplication formula ensures that the early levels take a little while to reach, with this effect becoming less relevant in later levels. These values will be tweaked once I have the content in place. I may have oversimplified this but I think it will be easier to tell once I have my 5 level demo.

Tiles in the game have a number of experience points assigned to them. You are awarded these points when you pass over them in the game (that is, you need to have successfully placed them on the board and been able to use them). The experience points will vary dependent upon the tile type and the widget applied (see a future post on crafting :). The experience points you’ve earned in the current level are displayed during gameplay (This shows you what you’re playing for).

If you successfully reach the level exit, you keep those points (otherwise they are lost).

You are presented with a screen that shows experience points earned, accumulated total experience points, current character level, and experience points needed for the next level.

Levelling up will give you a choice between 3 perks. These will be randomly generated but influenced by your current level. Potential perks are likely to include a special tile type, a quantity of basic tiles, widgets, a decent amount of gold, a new tile queue slot. These aren’t defined yet.

I’m also toying with the possibility of rewarding the player with something more minor (gold and/or basic tiles) for simply reaching the exit.

Balancing all of this is going to be a challenge. That’s another reason to keep the formula’s simple. The more complexity added here, the more difficult it will be to create a stable playing experience throughout the full game, across a wide range of players.

I’m also thinking about grinding. I think ideally I want to avoid it (especially with no stats to level). The easiest way to do this is to prevent the player from earning experience points when replaying completed levels.

Something else I need to consider is a level cap. This is essentially an artificial system for prevent overpowered players. Again, without player statistics, I’m unlikely to need to do this.

Level 1 Done

So, I’ve reached my level 1 milestone. Its now onto level 2 which means a new tileset, the loot system, and the quest system.

A few asides that I need to work on. The menu screens need an overhaul since I now dislike them severely. I also feel compelled to get some placeholder sound effects into the game. Oh, and the background for level 1 (or that tileset) is horrible so I’m going to rework it.

Stuff I liked this week

I totally omitted this the last few times. Oops! Anyway, here’s some interesting stuff from around the internet.

• https://twitter.com/#!/notch/status/195141690917523456 – Notch asked if any indies wanted to be included in his new game, 0x10c, as fictional software companies. I put Bytesize Adventures forward and it sounds like it was accepted – how cool is that?
• http://not.vlambeer.com/luftrauser/ – Play this web game.
• http://www.ludumdare.com/compo/ludum-dare-23/?action=preview&uid=1163 – I enjoyed this Ludum Dare entry.
• http://www.icoderogue.com/2012/04/game-level-and-rapid-prototyping-demo.html – This JS web framework looks pretty interesting. Its by @LZAntal. More on it here – http://raptorgl.com/
• http://frenden.com/the-little-monoprice-graphics-tablet-that-could/ – A Wacom graphics tablet competitor. Shame UK shipping is so expensive (still cheaper than a comparable Wacom though).
• http://www.makeuseof.com/tag/7-apps-coffee-lover-ios/ – Coffee Cellar was featured in a “7 Apps that every Coffee lover should own” article.

Thanks for reading. More Soon.

+ New GUI elements
+ Reworked tile queue to buffer taps and keep animations in sync
+ Wrote two transitions – one for the end of a level (puzzle) and one for the transition to a level within a level (more on that another time)
+ Basic graphics for level-up screen
+ Changed the way an inventory tile works. It now remains active until you dismiss it (or it auto-dismisses if the tile quantity reaches zero)
+ Started to draft a tile crafting (sort of) mechanism. This may sound like a huge feature but its actually a potential solution to a gameplay problem
+ Coded 2 basic fail states and 1 win state
+ Added basic menus for restarting the level and returning to the map screen
+ Tapping the timer takes it immediately to zero and begins player movement. A second tap increases the player movement speed.

Honestly, I had intended to focus on the character levelling side of things but I ended up just working on a bunch of random, less exciting stuff. The past few weeks have mainly focussed around the stability of the core gameplay mechanics. Level 1 is getting to the point where its giving a good indication of the minute-to-minute gameplay. As a result, its throwing up some issues with gameplay flow. A good example is my original inventory implementation which allowed for the placement of a single item before returning to the queue. I’ve revisited this and the chosen inventory item now stays in play until cancelled.

This may not seem very important but its these gameplay details that heavily impact the quality of the final game. Its balancing the good with the bad. Keeping the inventory item in play adds complexity to the controls (something I’m trying hard to avoid) but on the positive side it decreases frustration (and multiple taps) during gameplay.

I said I’d share an image in each of these updates. Here’s one showing the aforementioned queue and inventory selection system.

I need a few more things before I can move on to level 2.

• Player persistence – I’m currently thinking of using SQLite 3 for persistence.
• Basic character levelling – For now i’ll just implement the experience points and levelling (sans rewards).

That’s about it I think. There are still plenty of secondary concepts that need implementing

• Loot
• Gold (or some form of in-game currency – I’m not talking about freemium, I just mean a system for purchasing in-game items – like in most roleplaying games)
• Shops
• Quests
• Tile crafting (this will add an element of resource management to the game which could be quite interesting)

By then I expect to have a 5-level demo that showcases the majority of the games features. After that its back to the level editor, content creation, graphics, story, sounds, music, and really thinking about the special tile types.

No one said game development was easy :)

+ Artwork for speech dialogue
+ Artwork for character selection screen
+ Artwork for male NPC (non-player character)
+ Artwork for the three character classes
+ Started some artwork for the second tileset
+ Artwork for treasure chest (I’m not sure about it though, I think I’ll end up scrapping it and starting again)
+ Programmed character selection screen

You’ll notice that the main focus has been on artwork :)

For this blog post, lets focus on character classes. As part of the RPG (Role Playing Game) elements of the game, you’ll have the opportunity to select from one of 3 character classes. I’ve gone for the traditional Wizard, Fighter and Rogue.

When you start a new game, you’ll be presented with the character selection screen. At this point you have a choice. You can either let the game decide your class (“who am I?”) or you can manually choose one of the 3 classes.

Who Am I? – If you opt to let the game decide your class you’ll be presented with a series of fun little questions/situations and must select between 3 possible responses. These will allow the game to determine the class it thinks best represents you from your answers. You’ll remember this system from some older role play games. Hopefully it makes the game more accessible and also acts as a fun diversion.

Your character class will not limit you within the game (or at least that’s my current thinking). Instead it will purely dictate your starting bonuses. So, for example, a fighter may have access to additional explosive tiles whilst a rogue would get additional gold and perhaps start with more queue spaces revealed.

You’ll level your character throughout the game, giving you access to additional tiles, various perks (affecting attributes in the game), etc. You’ll be given some choice as to how your character levels, altering the gameplay to suit your play style.

I’ll discuss levelling in more detail soon. At the moment there isn’t a system in place other than a basic experience point concept.

That’s it for this week. Sorry its so short. What’s been lots of work has resulted in very little to actually talk about.

I’m still working towards my 5 level demo and I’ll start thinking about posting some alpha gameplay soon. Thanks for reading and feel free to post your thoughts/questions/suggestions in the comments.

Since changing tack slightly last week, here what’s been accomplished.

+ Implemented the inventory selection logic (explained below)
+ Implemented walls and explosives
+ Made good progress with level 1 of the demo

This week I’ve been building the first level of the game. Actually, It may not end up being the first level of the final game but it’s certainly the first level of my 5 level gameplay slice. If you missed last weeks post, I’ve essentially decided to build a short 5 level demo of the game (in order to test gameplay mechanics and hopefully show off some gameplay).

Side-lining the level editor is already paying dividends. It’s forced me to implement a few new tile types – the wall and the explosives.

The wall is primarily there to limit player choice (when trying to create a path), forcing them to think a little deeper about the solution. Currently nothing can destroy a wall tile, although I may experiment with this a little.

The explosive tile is a key component to the game since it mitigates some of the elements of luck within the gameplay. The tile queue serves up a new random tile each turn which can be placed anywhere in the level. In order to avoid a situation where you fill the grid with useless tiles, you’ll have access to explosives. These special tiles allow you to destroy any tiles on the grid that you have placed. Of course they’re a bit of a commodity so you’ll want to use them sparingly.

I’ve also focussed a little more on the player inventory. Primarily I’ve been trying to get the controls right. I don’t want to fill the interface with hundreds of buttons so I’m trying to create the right flow for the RPG elements.

Tapping a space in the level places the current tile from the queue. Tapping the inventory allows you to select a tile from your inventory (The game doesn’t have traditional loot such as swords and armour. Tiles are the games valuable items). You tap a tile in your inventory to select it which then closes the inventory. Your next tap will place this tile in a space in the level. Subsequent taps will revert to using tiles from the queue. I can think of a couple of scenarios that still need thought…

1. You need to be able to cancel your selection (I’m currently thinking a tap on the next tile in the queue).
2. The player will need to be reminded of which tile they have selected from the inventory. The simplest way I can think to achieve this is to temporarily replace the next tile in the queue.
3. The player will have to constantly open and close the inventory if they want to place lots of the same tile from their own stash.

The next step is to complete the first level. I still need a few more things to achieve this…

• I need to work on the character models (I have a plan for this)
• I need to get the NPC speech graphics in place
• I need to implement end tile logic
• I need to implement player persistence
• I need to implement the experience point mechanics

Then it’s on to level 2 which involves a whole new tileset (I’m planning a good amount of location variety in the final game so that things don’t get stale visually). I’ll also be implementing the quest logic.

Level 3 will see a new sub-location concept (which I still need to experiment with).

Levels 4 & 5 are reserved for experimenting with quest mechanics and new tiles.

Remember this is a mini-slice of the game so that I can test concepts and present some kind of demo. The final game will have many, many more levels and tricks up its sleeve ;)

Stuff I liked this week

I thought I’d add a new section to these blog posts to share any interesting stuff I find. Here you go…

• http://space.angrybirds.com/launch/ – The Angry Birds Space website. Pretty nifty.
• http://www.youtube.com/watch?feature=player_embedded&v=OLqk4aqpXlQ – The Portal 2 postmortem from this years GDC.
• http://www.sauropodstudio.com/dev-diary-number-five-redesigning-the-bricktron-character/ – Really enjoying the Castle Story dev diaries.
• http://www.design3.com/industry-insight – Loads of great game development interviews.
• http://www.indiegamemag.com/dont-get-me-started-on-the-penguins-tiy-talks-upcoming-space-epic-starbound/ – Starbound is looking great.

Until next time.

Completed this week…

+ NPC (non-player character) placement in the level editor

So, what caused the issue last week? Well, its my level editor. I’m 100% convinced that building a level editor for this game is the right approach. I also know that I want it to be visually appealing (or at least tidy), easy to use, and also fun to create levels in. The last one may surprise you but if I’m going to spend hours and hours building levels with this tool, the process needs to be enjoyable. As a result, building the level editor is extremely important.

You may recall that last week I added NPC’s to my engine, along with a data structure to support them. Much of my time in the last few weeks has been spent thinking through the interface for authoring this in the level editor. I have finally managed to program the functionality for NPC placement but it has been painfully slow. Each time I add a feature I need to design the appearance, program the functionality to display it on screen, add the models for saving to a database, extend my xml generation script (for producing the level data that’s served to the game), and extend my level parsing to allow the loading of levels within the editor. I’m sure you get the point, its a lot of work for very little immediate benefit.

Compounding this work is the fact that some of these concepts are experimental (until I know how well they work in the game). I also have lots of outstanding features that are not yet in my engine. As a result, I’m going to change tack slightly this week. Rather than iterating the level editor along with the game, I’m going to park the level editor (for a few weeks) and focus on creating a handful of levels in the game. I’ll still be writing the data structure to support them but I can compose them directly in a local plist.

This will allow me to shift my focus back to game features. I need to see how well the game plays across a number of levels. I can also test some of the concepts I have in mind for quest structure, story, character persistence, and level progression.

So that’s my new goal. A 5 level mini-story to demo the features of the game. I can come back to the level editor once the concepts are more entrenched in the game engine (and proven to work).

I am interested in how other developers handle the creation of a level editor at the same time as a game. Do you create the level editor first, iterate throughout game development, or leave it to the end? If you have any insights, I’d love to hear them in the comments.

I’ll leave you with another tile piece. More to come soon.

+ Added NPC’s to the game engine & a data structure to support them
+ Added basic NPC interaction
+ Added NPC rewards
- Slight overhaul of the player movement logic

As you can see, this week my primary focus has been on NPC’s. Whilst I’m moving on to other sub-systems next week, you’ll be hearing/seeing more about NPC’s in the future. For now, I just wanted to share some of the basics with you.

My current NPC interaction is very basic. As you progress through a level/puzzle you will see NPC’s who can be approached (providing you can create a path to them). Successfully occupying the same tile as an NPC tile will result in one of three conditions (or a combination thereof). The first is the initialisation/progression of a quest fragment (more on that in a future post), the second is a conversation, and the third is a reward.

Currently a conversation is one sided with a simple text dialogue giving you some information or progressing the story – the story is very much told through the levels themselves so this is used as an accompaniment to that.

Rewards generally take the form of a number of tiles. Sometimes these are core tiles, sometimes special tiles. I’ll share more about the reward system in a future post :)

Unfortunately there’s not much to see visually on the NPC front. Its all rather ugly because I’ve spent all of my time ensuring its functional and no time on the aesthetics (NPC appearance, text appearance, reward popups etc). As a result, this weeks image is a photograph of a board game that has been a huge source of inspiration for my current game.

Next week I’m switching back to the level editor to focus on the authoring side of my NPC system. I’m also hoping to create the graphics for two more of the core tile types.

See you next time.

This then is a list of video game soundtracks to listen to whilst you’re coding your next big game. This isn’t an exhaustive list, I think that would be pointless, instead its a list of soundtracks that I think represent the best (I’ve added links or embedded the music where possible).

I’d love to hear your recommendations in the comments – I’ll aim to keep the list updated.

The Binding of Isaac (by Danny Baranowsky)

(Bandcamp)

Aquaria: Original Soundtrack (by Alec Holowka)

(Bandcamp)

Portal 2: Songs to Test (by Aperture Science Psychoacoustics Laboratory)

(Website – Free)

Shatter – Official Videogame Soundtrack (by Module)

(Bandcamp)

Sword & Sworcery LP – The Ballad of the Space Babies (by Jim Guthrie)

(Bandcamp)

PPPPPP – The VVVVVV soundtrack (by SoulEye)

(Bandcamp)

Minecraft – Volume Alpha (by C418)

Mainly just the theme though – track 8

(Bandcamp)

Bastion Original Soundtrack (by Darren Korb)

(Bandcamp)

Super Meat Boy! Soundtrack (by Danny Baranowsky)

(Bandcamp)

Cthulhu Saves the World (by Gordon McNeil)

(Website – Free)

World of Goo Soundtrack (by Kyle Gabler)

(Website – Free)

This week I’ve hit a fairly crucial milestone. I can create a level in my web based tools, export it, and play it on my iPhone – all without needing to type a single line of code (or even opening Xcode). I’ve thrown together a quick video for you (embedded below). Watch it, and then read on for an explanation of what’s going on.

To explain what’s going on in the video. The point of creating my tools on the web is to enable me to author levels anywhere (or at least on any device that has a browser). To demonstrate this, the video above shows the level editing tools running in mobile safari on the iPad. In theory all I need is the iPad, my iPhone, and a cup of coffee and I can create content for my game!

The video shows a toolbar across the top and 3 panels in the main view. The toolbar is currently used purely to load existing levels for viewing and editing.

The panel on the far left is the level being created (the canvas). Its comprised of a grid of 30 squares, all of which contain a tile (or not). This defines the tiles displayed when the level starts – soon it will also define behaviour, npcs, quests, etc.

The middle panel is the palette. These are the tiles available for creating the level.

The panel on the far right is the level meta data. It dictates the level name, reference, and its tile set (which impacts the tiles available in the palette). It also houses the controls to save the level and export it. The final piece of data is the context which is used purely as an aid for describing the current tile.

The video shows the creation of a level using these tools. It then pans to the iPhone which is running the game. The black screen is a temporary level select screen. Hitting refresh polls the tools server for the latest level data. You can see that upon hitting refresh the level just created appears in the list. Tapping that level loads it into the game engine.

I should point out that the gameplay shown in the video is extremely early. Its meant purely to demonstrate the tools.

The next step is to focus on NPC’s and the quest system. First i’ll be writing the components in my game, then adding the parsing to my engine, and finally writing/adding features to the web based level editor to enable me to author them.

This is very much an iterative approach. I’m don’t yet have the features to create a single level and it will be a little while before I do. However, when I reach that stage I’ll have some fairly solid tools to allow me to create the rest of the levels. It all about playing and iterating.

So everything is coming together nicely. Hopefully next week I’ll have some NPC interaction to show you :)

AltDevConf is a spin-off of AltDevBlogADay, a blogging website setup by Mike Acton to encourage game professionals to blog more (Inspired by Miguel’s very own iDevBlogADay).

You can checkout the conference schedule here.

There are a total of 23 sessions split across three tracks – Programming, Education, and Design & Production. Here are the sessions I attended…

Saturday

• Design & Production: Intro to Producing for Mobile: how to “go indie”, actually ship an app, and not die.
• Design & Production: Scrum Bowling: Agile Production Methodology for Indie Teams and Student Projects.
• Design & Production: How to create a positive online game developer community.
• Programming: Control, Configure, Monitor and View your game engine from the web.

Sunday

• Programming: Understanding the second generation of behaviour tress and preparing for challenges beyond.
• Design & Production: Effective PR, Marketing, and Community Management in the Indie games space.
• Programming: Games Tools as a WebApp: Lessons from Insomniac’s Next-Gen Tools and Engine.

Design & Production: Intro to Producing for Mobile: how to “go indie”, actually ship an app, and not die

Speaker: Evangeline Marzec

There was some good information in this talk. Its a fairly emotive subject since so many people are now jumping on this bandwagon. The session very much focussed on the business side of App production and ensuring you build a stable business first and foremost.

Some general notes I made…

- Cycle through 100 good ideas in order to find a great one.

- Give Luck a small role in your business.

- Define success and failure for your business. These are important for knowing when to continue/quit.

- Choose tools wisely. Don’t choose tools that will require the production of expensive assets (Unity was used as an example).

- Focus and market research and know your competition. Also mentioned was not developing Apps in a niche that appears dead.

- iOS first, port later. I have to say I’m not sure about this one. The speaker was making the point that Android only represents on hundredth of their iOS revenue. I think it depends entirely on the experience you’re creating though as to which target platform you choose.

- You need a minimum of $2k to make an App! This one hit a bit of a nerve for me and, if my twitter stream is anything to go by, other indies too. I checked with the speaker and included in this figure is assets (sounds etc), minimal hardware, license, middleware, and time. That last one is where the figure seems way off. The speaker put developing an App at anything from 3 days to 2 weeks. My experience is that a well produced game/app takes a minimum of 6 months. I guess it totally depends on how you value your time.

In all fairness, this is one persons view and its clearly working for them because they’re running a successful business (something that I certainly can’t say is true of my Apps/Games).

- Get a good book keeper. Pay someone else to do this so you don’t have to.

- Backup your data and keep records.

- The speaker also shared some financial stats. Their first App made $947 in the first week (due to an Apple feature). The second made $12 in its first week. Their 3rd App made $0 in the first week. I wasn’t able to get any more information on this but this seems to reflect the kind of stats I see and hear about. The App store is getting more and more competitive and more difficult.

- Know when to walk away from a project. Couldn’t agree more – See my own iPhone game graveyard.

- Pay yourself a salary and allow yourself a bit of luxury.

- Get a mentor.

- Do what you’re good at.

Design & Production: Scrum Bowling: Agile Production Methodology for Indie Teams and Student Projects

Speaker: Margaret Moser

The speaker mentioned that they haven’t followed Scrum to the letter and have instead rolled their own – specifically rolling up sprint reviews, etc into a single mega-weekly-meeting. I think this is important since Scrum reviews are designed specifically to improve/tweak the Scrum process to better fit your company/team/project.

Some general notes I made…

- SMART tasks – specific, measurable, agreed upon, reasonable, tied to a specific time interval. Your tasks should meet these criteria.

- Estimate each team members availability each week since this changes depending on commitments.

- 81 attendees. 14% of attendees were familiar with Scrum. Some openly dislike it. I asked how many were managers vs dev – 13% were managers vs 37% devs. I was wondering if there was a correlation between who disliked Scrum and their role within a team.

Unfortunately we lost the speaker at this point. Mike Acton stepped in and chatted a bit about his own experiences with Scrum.

For my own part, I introduced SCRUM at work so I have some experience with this. Personally I think its a good development methodology. I think some people expect it to be a silver bullet, which it isn’t. It takes hard work and effort to get everyone engaged with the process. What it does though is give you better control/metrics for making educated responses to project progress and it increases accountability and engagement.

Design & Production: How to create a positive online game developer community

Speaker: Ryan Arndt

This talk focusses on tips about maintaining and growing a community. I have to confess that I didn’t get quite as engaged with this talk because it just didn’t resonate with me. The talk itself was very well presented though and, if you already have a product with a semi-engaged community, it contained some useful tips.

Here are my fairly minimal notes…

- A community doest maintain itself

- Inclusion. Welcome people

- Engage with people on their platform of choice. Don’t expect them to move their communication to a single central place of your making.

- Arrange community news/events (http://www.igda.org/gamejobshashtag)
- Crowdsourced contests
- Casual/light – community shouldn’t take itself too seriously.
- Ask open ended questions
- Share positive content (e.g. when game does well)

- 3 strike rule for banning.

Programming: Control, Configure, Monitor and View your game engine from the web

Speaker: John McCutchan

This talk was really interesting. So interesting in fact that I didn’t take quite as many notes as I would have liked. Moving tools and monitoring to the web is something that I’m really interested in. You probably know that I’m creating web based level editing tools for my next game. Its great way to remove the constraints of traditional tools. The talk was really engaging and very clearly presented.

Here are my notes…

- Simple to create GUI’s

- Reduced interation time

- Don’t need to be physically near the tools

- Webgl caching, live performance monitoring, live editing, remote viewing.

- For remote viewing, achieving 30FPS at “good enough” quality – 2MB/Sec though so too much bandwidth remotely, ok locally.

- Web based means easy to update, approachable, easy to demonstrate game changes, browsers getting faster every year

- Why web socket? New web app protocol, TCP connection with tiny overhead, message based, bandwidth reduction.

- Why JSON for data? key->value, easy to parse, text based.

- Interface – JS generates all HTML dynamically.

- How?
- 1: API for engine tools
- 2: expose API as JSON over web socket
- 3: build engine tools as web App

- Thinking of porting to Dart due to JS limitations.

- www.johnmccutchan.com

Programming: Understanding the second generation of behaviour tress and preparing for challenges beyond

Speaker: Alex Champandard

This talk was all about behaviour trees. The talk focussed predominantly on code based examples, reviewing 1st gen vs 2nd gen trees. It was certainly interesting although I’m not sure when I’ll have the opportunity to employ something like this – unless its just for fun of course :)

Here are my notes…

- 4 prototypes shown – 2 first gen, 2 second gen.

- They’ll be open sourced later in the year on github. For now check out http://aigamedev.com/

- Motivation – behaviour trees are everywhere (halo, spore, red dead, etc). Used in AI, squad logic, animation etc.

- 1st gen vs 2nd gen – behaviour trees changing fast. having to due to complexity of games and expectations.

- MoveToCover (action), hasAmmo? (condition) – both behaviours

- trees are comprised of sequences (fixed lists of statements) and selectors (conditional branching). A sequence happens in order – failure breaks it. A selector tries all children – individually report success.

- More selectors at top of tree and sequences later in tree.

- That is simplest form – each NPC needs a new tree (memory issues).

- Nodes and tasks.

- 2nd generation. Specialised interpreter for processing behavior trees (rather than relying on pure C++)

- Shown 2 examples, Data oriented behaviour tree and Event driven behavior tree

Design & Production: Effective PR, Marketing, and Community Management in the Indie games space

Speaker: Erik Johnson

This was a really interesting talk. Most of what was highlighted wasn’t particularly revolutionary but it was helpful having it brought together and hammered home (with examples). I particularly liked the focus on engaging with the community and leveraging word of mouth (your community become you game evangelists).

Here are my notes…

- Respect customers. bad example of this: http://www.penny-arcade.com/resources/just-wow1.html

- Dont be defnsive and dont take things personally.

- Let customers know someone is on other end of line.

- Members may become evangelists for your company.

- Website, blog, forum – should do this as minimum. As long as you maintain them otherwise dont expect them to be active.

- twitter, youtube, facebook, google+, indiedb, reddit, n4g, etc.

- Be open with development

- Consider public alphas, betas – http://www.wolfire.com/

- Be creative/human – find out what community is into.

- Exposure – podcasts, lets play videos, local media etc

- Let peers know about your game to help spread the word

- Research where to reach your potential audience (niches etc)

- Dealing with press – be unasuming, frank, generous (screenshots, interview, keys etc)

- Organic marketing – open development, word of mouth

- Malleable marketing throughout dev process – go with opportunities, change marketing plans to fit, trial and error, know whats appealing about your game (especially what others perceive as appealing – highlight these in your marketing screenshots etc), trust your instincts.

- Take risks, get creative. Bundles, etc

- Tie it into the game content – e.g total crates collected tied into content releases.

- Know when to shut up. Leave people wanting more. Understand balance. Keep a few aces up your sleeve – leave stuff for people to discover.

- Consider price point – no permanent price drops in first 6 months

- Consider platforms, promotions

- Exhibiting (show game off), kickstarter

Programming: Games Tools as a WebApp: Lessons from Insomniac’s Next-Gen Tools and Engine

Speaker: Mike Acton

Along with the web monitoring tools, this was the talk I was most looking forward to (because its so relevant to my current game). It certainly didn’t disappoint and was interesting throughout. I picked up some interesting tech to look into that I hadn’t considered and it also confirmed my choices in some cases. I would have liked to have seen more of the tool demoed but you can’t have everything right :)

Here are my notes…

- Picked single browser to avoid browser cross compat issues (Chrome)

- 3D window is custom plugin

- Tools are html and javascript

- Forward thinking. seemed to be where future lies. expectations of new developers.

- Forces data division. Avoids hacks.

- UI dev costs are lower (JS and HTML)

- Opens development up to programmers outside of traditional engine/tools team

- Not a mature platform yet so difficulties exist not present in traditional tools dev.

- Challenges part and parcel of game dev. learn as we go. better to do it now.

- Web server on each client machine (Mongoose) with asset db (MongoDB), asset files (backups stored on disk), source files (referenced), file tracker (tracking changes), build manager (managing build process), comms via REST, UI (html5, css3, js), scene editor (native plugin), scripts. Also shared server (logging, help/videos,feedback system,asset comments).

- Had considered flash (years ago) scaleform. Also used to have a standard stack apache/mysql but installation etc too time consuming.

- Asset updating was on-demand, now immediate

- Scene editor (native plugin) – will run any native application (security fine because its internal)

- jQuery used but building custom controls (rather than prebuilt components such as from jQuery-UI).

- Difficult Q’s – File naming, auto-saving disconcerting (switched to manual)

- Installer was difficult as was fighting some of the built-in browser security (xss)

- Undo/Redo was difficult

- Had to build in ability to bring down/up individual system components

- Had to add login to track who was using tools

Conclusion

Overall the conference has been excellent. Very well organised and, despite some technical hitches, things ran very smoothly. I was expecting much more latency and technical issues that simply didn’t happen. Its a credit to the organisers and all of the speakers.

You should definitely make room in your diary for this event next year. Its fun, free, and a great opportunity to learn something new.

- Reworked the tile queue system
- Added a temporary GUI – Please ignore the appearance, its nowhere near final.
- Added player
- Added player movement/pathfinding
- Added the timer
- Added very early experience point mechanics
- Progressed the web based level editing tools (Level DB saving and plist export)

Lets take a look at a couple of the more interesting items from that list. First up, the player movement. You don’t have direct control over the main character. Instead, he will follow the path that you have laid down. The level is based upon a straightforward grid so pathfinding is fairly simple to implement (I have a tile class with edge attributes to determine which edges are open). Your character won’t begin moving until the timer reaches zero, at this point he’ll slowly begin to move along the path. Its your job, during the timer and after, to ensure that your character can reach the destination.

(As an aside, the character you see below is a placeholder. I have an aesthetic in mind and some fun RPG tropes to go along with it :)

Experience point and levelling mechanics are something I want to discuss in greater detail soon. For now I think its enough to say that you’ll gain experience points by laying tiles (only awarded upon successfully reaching the exit) and this will allow you to level your character, receiving appropriate perks/rewards.

Finally, the web based level editing tools are taking shape. Whilst they barely look any different on the surface, beneath the hood I now have a level database. This represents the pool of levels that make up the game. I can save to this and, soon, load from it and modify the items. I’ve also created an export that generates a single plist from all of the level data. My game engine already parses this to generate the level. I’m hoping to access this plist remotely (during development) to give me a near-realitme level editing facility.

Next week I’m going to continue to flesh out the level editing tool and work on an over world map (for now this will just be a list of levels, for speed. I have grander plans for the finished game). I’m also itching to move onto the quest system so I may dabble in that too.

More soon.