Category: devdiary

Categories
dev-process devdiary entity systems games design programming Unity3D

2015 talk: Progress on An Entity System for #Unity3d

Slides from my talk last night at Unity Brighton.

Three parts:

  1. First: introduction / overview of Entity Systems, and why you care (as a “person who makes games”)
  2. Second: Progress so far: screenshots of the Unity Editor with explanation of the new features I’ve added
  3. Third: Challenges and solutions I’ve encountered so far

Aliqua-progress-2015-BUUG-v3

WordPress, HTML, the web etc – don’t support “presentations” yet. No, I’m not creating a fake Slideshare account just so you can wait ages for a non-bookmarkable slide viewer to (slowly) load. Until then … we have PDF. Enjoy!

Categories
computer games dev-process devdiary entity systems games design

2014 Entity Systems: what are your Unity3D questions and problems?

In 2014, I’ll be making a new game in Unity that makes intensive use of an Entity System.

This will give me lots of ammo for a new post exploring the pros and cons of Unity’s “partial” Entity System architecture. I’ve been thinking about this a lot for the last couple of years, but I’ve been unhappy with the draft posts, and didn’t publish them.

Over the next couple of months, I’d love to hear from all of you the challenges, confusions, problems, and questions you have about this. I’m not promising quick answers – but it will help shape the blog posts I write, and as soon as I have a good enough set of answers, I’ll start posting them :).

Continue reading “2014 Entity Systems: what are your Unity3D questions and problems?”
Categories
android devdiary games design

Prototyping: Chess Quest v0.3

(I’m prototyping a new game (working title: “ChessQuest”) – original post here)

Three major changes:

  1. You have a health bar, and can die
  2. The trackball is now supported for movement
  3. Performance is literally 1.5x – 2x faster

Download link

Chess Quest-0.3.3

So, a friend of mine tried it out today, and he couldn’t move around at all – something wrong with his HTC Desire (even though I’ve been testing on near-identical phone, for some reason his phone was losing the input gestures). This evening I did some improvements and fixes until it began to work “tolerably” on his phone – and I threw in some new small features too.

It’s still test stuff – not indicative of the final gameplay, but I’m trying out different basic ways of achieveing the stuff I want to achieve in the later versions.

Overview of what’s changed

  • You have a very basic HUD
  • There’s a couple of coloured powerups scattered around – red restores health, green increases maximum health permanently
  • Enemies actually kill you now, every moment you’re touched by one, your health drains continuously
  • You can choose different levels at the start – I included one of the early test levels that was easy for me to upgrade with recent changes. I’ve got another one I can probably add quickly later (one which generates 100% random mazes each time you play)
  • The ultra-simple EntitySystem I’m using was running too slow. There’s no simple fix I can see – the ES really needs to be written for performance, if I want it to be high performance – but I was able to do a 10-lines-of-code workaround that took the worst piece of bad performance in my game and made it literally 5 times faster. That’s good enough for now!
  • Input system has changed *again* – the Android OS has poor input management, a bit buggy, with an inconsistent programming API, which *also* runs differently on different phones – so I keep trying to do as little work on this as possible. The Android OS is desperately trying to prevent me from doing any prototyping at all – it’s begging for me to write hundreds of lines of code to make up for Google’s inattention there – but if I do that, I will lose all the time I would have spent doing game design and dev, and the whole project will be a failure. So, yet again, I’m putting on a band-aid and dodging the rest for now. But … at least now you can use trackball instead of / in addition to swiping on the touchscreen
  • There’s an FPS counter on the screen
Categories
android devdiary games design programming

Prototyping: Chess Quest v0.2

(I’m prototyping a new game (working title: “ChessQuest”) – original post here)

A couple more hours work, a few more changes:

Overview of what’s changed

  • Obvious from the screenshot: added alternating black/white background tiles. I want it to feel like the traditional chessboard has become the “floors” of the dungeons/towers you’re exploring
  • Major fixes for collision detection: player and enemies now do pixel-precise collisions (previously, if e.g. a piece moved 5 pixels per tick, it would move either 0 pixels (if 5 would collide) or 5. Now it moves “as many pixels as it can before the collision happens”)
  • Major upgrade to renderering: instead of just “render everything, in random order” it now sorts all sprites once per frame. Each sprint is instantiated with a sort-layer; things in the same layer are rendered in random order, but before all things in the next layer
  • Minor tweaks to movement: not happy with this, but I found the “never stops moving” annoying. Now I find the “stops too easily” annoying.
  • Various experiments with zoom level – I tried 20px, 32px, 64px and 100px (very zoomed in!). I found 32 px was working nicest on the Nexus 1, so I’ve stuck with that for now. In a future build, I’ll probably bring back the option to switch to a zoom level of your choice.
  • Added Flurry: I’ve never done this with a prototype before, but then I’ve never prototyped in public :). I’ve added Flurry just so I can keep track of how many people are running the prototype; as I add to the prototype, I’ll start adding in-app feedback options, so you can effectively “vote” on things you like/dislike, and I’ll use Flurry to graph it all automatically.

Download link for this version

Version 0.2

Categories
android computer games devdiary games design

Game prototype: Chess Quest

Last weekend, I was playing around with some ideas for a Chess / RPG mashup. I did some prototyping with Android (because iPhone apps can’t be shared, and Java is much faster to debug than ObjC).

If you’ve got an Android phone, try this, and let me know if it runs:

There’s not much you can do – touch and drag on the screen to move up/down/left/right (you’re the Rook – hence no diagonal moves). Bishops and pawns wander around randomly, pawns slower than bishops.

UPDATED: if you rotate the screen sideways, it’ll randomly pick a different size / zoom level. There’s four sizes, from 20×20 squares up to 100×100 squares. Player moves at different speeds based on the size too.

I wanted to make it a dungeon-exploration style, but with a Chess theme – and (like in chess) each time you complete a dungeon (kill the boss) you get to “pawn” and switch your character to the chess piece you killed.

i.e. first boss would be the Rook, second the Bishop, third the Knight, etc.

…but I’m not sure I’ll stick with that. If I get some more time this weekend, I’ll prototype a bit more.

NB: the APK above might run slow – I’m interested if it looks jerky / doesn’t work on your phone. It runs fine on an old Nexus One.

Categories
devdiary entrepreneurship games design iphone startup advice

Volunteer project: a simple RPG for iPhone – UPDATE

A lot of people asked me to blog as this volunteer project progressed, share some insight into how things were going. I’ve not had enough time until just now, and it’s a mix: Some good news, some bad news.

Continue reading “Volunteer project: a simple RPG for iPhone – UPDATE”
Categories
computer games design dev-process devdiary games design iphone

Dungeon Master Clone for iPhone – Concept GUI

(c.f. my original post here: http://t-machine.org/index.php/2009/06/28/want-to-help-write-a-simple-rpg-for-iphone/)

I’ve been playing around with GUI setups for DM / EOTB / Wizardry clones on iPhone, and thought I’d post some of the more interesting results here – I’m interested to see what other people think of each of them.

The first three are all assuming a single-character RPG, the fourth is something more like DM / Wizardry (could be 6 chars, could be 3).

Everything is clickable – small maps become full screen map, blue buttons fire spells, character portraits go to the inventory screens.

Screens with no arrow buttons require you to drag your finger forwards/backwards/left/right to move, and allow 360 degree movement. Screens with arrow buttons assume you can only turn 90 degrees at a time (like the original games), although they smoothly animate the rotations (UN-like the original games – because I have access to OpenGL to do the 3D for me).

What do you think?

concept-ss-1

concept-ss-2

concept-ss-3concept-ss-4

Categories
devdiary games industry startup advice

Salaries for startup directors / executives

This is in two parts – the problem that lead to me even caring, and then some very interesting conclusions that can be drawn from looking at last year’s aggregate data on how much tech startups ACTUALLY pay their execs. A lot of random speculation is thrown in, I don’t stand by most of it, but it’s interesting how much stands out just from looking at the aggregate data.

PS: to all the people reading this blog for the MMO tech stuff, I hope you don’t mind the shift to a lot more business stuff lately. This is what happens when you put together a new startup :). I promise there’ll be more MMO-specific stuff in future…

Continue reading “Salaries for startup directors / executives”
Categories
agile devdiary programming

Writing games in Korean – part 3

Computer grammars, Unicode in Eclipse, and problems with Java’s XML parsers…

Continue reading “Writing games in Korean – part 3”