next »

[Triplefox]

Play now

Game's concept and title have changed.

Original Text

This is a tycoon game about building/programming/organizing robots to run a retail store for you.

I have done nothing to implement it yet. There is no design. This is a bold experiment for me and I figure a devlog will help me commit to it. A small prototype showing basic simulation of robots and customers should be ready sometime either this weekend or next week.

[Triplefox]

Quick update. Real update maybe tomorrow. My time has been split between moving, some tech work(making even low-level engine data structures like events serializable), and this phase distortion synth project. I just got my pathfinding code together tonight, so all I need to do for my prototype is get the pathfinding graph serialized with the other data, make it display, and then add a bit of interface and actor code.

Tomorrow or Friday, I guess, if nothing else comes up.

Design-wise I've decided that the most interesting thing the robots could sell is equipment to fantasy adventurers. By selling them appropriate stuff they can go out and level up and then spend more. Lots of multi-layered system dynamics potential going on there.

[Triplefox]

http://dl.dropbox.com/u/254701/builds/blancmange/12_19_2010.swf

On Friday, with the morale boost of being at the South Bay Jam, I moved from "derp derp engine tech demo" to really building the game. Then on Saturday I cleaned up some leftover issues and optimized. Still not where I wanted to be with the actual gameplay, but:

• There's a scrolling tilemap(two layers in fact, one is an overlay).
• Clicking the map makes the character walk around.
• Pathfinding is done with a Manhattan-distance A*, and you get to see the graph generated by pathfinding as you click around.
• Pressing the "any" key saves the entire game state to Flash local storage and then recalls it. You can do this at any time, mid-walk or whatever, it will work correctly.

And underneath there's a ton of engine tech to handle all the scenegraph management and positioning and events and tweening, while keeping everything easy to serialize.

My two goals for next week are: expand the actor count so that I can do the robot/customer prototyping, and then capture the art style:



I want to do a higher-res version of this kind of iconic minimalism. I want to stay away from overly detailed graphics for two reasons: Without a dedicated artist, it'd take too much time and I don't have enough skill to do a really great job. As well, coding for most representational styles would mean moving from pure tile rendering to some form of perspective. More code, more hassles, and overall more cumbersome for gameplay. And as an added bonus, working from this style helps focus the game's theme further, since it's so firmly associated with classic RPGs. It already gave me the idea of having the store owner be a character that can adventure around the map, rather than the omniscent god of most tycoon/sim games.

[Triplefox]

Now I have a player sprite.

Even knowing what I was going for, it took me a few tries to settle on a style guideline for character sprites that retained the desired aesthetic with a 32x32 resolution:

• Character uses a single saturated color at two brightness levels.
• Details allowed only where they complement the primary shapes.
• 1px black outline to allow the sprite to pop on all backgrounds.

Increased resolution seems to pull pixel art towards increased detail as well. It's really hard to fight this.

Next I will test some landscape ideas.

Edit:



Moved to colored outline and started using it as the "linework" color. Brought out what I was really looking for, I think.

[Triplefox]

After trying my first concept/mockup pass and giving it a little while to sink in, I'm finding the early Ultima look too lacking when directly translated into a higher resolution. I can't find anything to work with in the dot-pattern landscapes, so I'm taking some new references for further inspiration.

HOMM(mainly 1-3):



Or possibly Wesnoth:



I still don't want to go for so much detail though. So maybe like HOMM with flatter colors and more cartoon shapes. That game was very easy on the eyes, unlike all the ones that stuck to a "real" perspective.

I'm starting to think that the "shopkeeping" part isn't really the focus of the game - it should be an entire town, so that it can capture a lot of detail as the Ultima series did, only in a more "simmy" context than a "scripted" one. This will make the focus and feel remain consistent throughout. It won't be like Dwarf Fortress, necessarily, since it's not trying to be meticulously detailed - rather, it's more of a sandbox for the large-scale systemic interactions between the town(which you control with your robot workers), the adventurers, and the monsters.

It's also a kind of statement on the future of our own world and what we will be doing, if all our mundane tasks are automated. So it's an art game too, ha ha. Name change will be needed. From "RoboRetail" to "RoboRuler" or "RoboVillage," maybe.

[Triplefox]

More small bits of progress, a lot of behind-the-scenes things:

• New tileset mostly ready. Have to do some coding to integrate it.
• Figured out how I want to integrate the tileset. I plan to use a border based on alpha masking. My basic background graphics are actually 64x64, and cut up into four pieces. I'm debating between "cache as many borders as possible" (which can be quite memory intensive) and "render most things on the fly" (which changes my tilemap model quite a bit, and hurts runtime performance a tad when scrolling around.) Leaning towards the latter - even though it means reworking the tilemap code it's faster to get running and plays better with HW accel, which is just over the horizon in Flash 11.
• Dicked around a ton with the pathfinding implementation, first adding A* with a Manhattan heuristic, then doing some micro-work, and then made a huge breakthrough tonight with a single optimization - using a real heap-based priority queue instead of a sorted list. The brought my stress-test (a new path on every rendered frame, going from corner to corner) from ~10.5 FPS at 128x128, to 25 FPS at 512x512, and 44 FPS at 256x256, which is what I'll stick with for map size. Previously I've never needed to do this scale/frequency of pathfinding, so I had to do some thinking+learning first to implement A*, and then to discover the necessity of using a heap to get the much-vaunted performance. Previously I had always done naive Dijkstra, which is exhaustive, so it doesn't need any form of sorting or prioritization.
• Refined the design concept a little more. Now it's a game in two parts - the first part is the adventure mode, a pretty straight-up loot+kill RPG with a randomly generated map, crafting, a Foozle or MacGuffin to work towards, and some monster AI. That will be its own game, and I'm planning to have the basic game done in two weeks, with a polished build following in a month or two. The second part is the sim/tycoon stuff, which I can add little by little, after I've made the basic RPG game fun.

I ate too many chocolates tonight. The sugar is getting to me.

[Triplefox]

http://dl.dropbox.com/u/254701/builds/blancmange/1_13_2011.swf

New build, demonstrating:

• Randomized map, based on a connected graph(starts from a grid and then does disconnects/jitters/subdivides/branches/relaxes). Final map is converted to tiles - this part is still very unfinished, I need to mix in more terrain types and "natural" landscaping.
• Tileset, particularly the grass, mountains and trees. Mountains may get another pass, they warrant a "perspective" treatment and my first experiment to provide such failed.
• Tile auto-bordering. This is actually pretty tricky; each tile is a composite of various subtiles and alpha masks. I also cache the resulting bitmaps to lower render overhead, albeit it's still a bit expensive just to compute a composite, with all the border relationships involved.

There's an error where visible cracks appear if you have the browser super big. It's not supposed to be played at non-native res anyway...

Design changes:

The game is now called "Magnate" and is more directly influenced by these games: Hinterland, Dwarf Fortress(and other Roguelikes), Majesty, Minecraft, Heroes of Might and Magic, Master of Magic. My whole "command robots" idea may still reappear at some point, far down the line, but for right now I'm focusing more on having human-type characters whom you command, running a fantasy village. There won't be any cut-down version, I'm going straight for the full game in one shot.

I am taking an approach to design called "Cycle modelling," a theory that I'm developing simultaneously. The concept is to plan and analyze design as a set of interlocking cycles. Each cycle describes a set and pacing of interactions, narrative, and psychological elements; some are "arcs" more than "cycles," with a linear end, but can occur repeatedly.

In my analysis of most successful games, "good" cycles are ones that players like to complete and are given incentive(however trivial) to participate in - for example, the process of item collection in platformers, or the build/mine/build cycle of Minecraft. In a multiplayer or vs. AI scenario, breaking the cycles of others is also a source of fun. When occurring over long stretches of time, cycles cause addictiveness to seep in, as the player willingly engages in dull/repetitive behavior simply to reach the end of the cycle. But players can't be left in the dark: they have to be made aware of cycles, especially ones that hang "just out of reach," to have any incentive to play a game. This is the "depth/accessibility" balance.

In this game I will focus on three overarching, easily-interlocking cycles that describe "being a fantasy ruler":

• Build the village economy
• Train/mobilize the army for defense
• Go on quests and adventures

And I'm now setting a target for some of the "build village" elements to be playable at the end of January. So you'll be able to plant crops and direct some NPCs to harvest them. Maybe no buildings yet, we'll see what happens - though I intend to allow terraforming of the entire map eventually.

[pixhead]

Im enjoying this devlog 

[cosec]

This looks interesting, gonna be keeping an eye on it!

[Triplefox]

http://dl.dropbox.com/u/254701/builds/blancmange/1_19_2011.swf

My first pass of world generation is complete. Most of the difficulty came from the whole tilemap thing. The final system is quite complicated and goes like this:

• 1. Draw water tiles. (water scrolls and so it's handled apart from other stuff)
• 2. Draw "blend" layer. This is the basic grass/sand/snow/etc. terrain, and I build the tile with a general compositing system that prioritizes and figures out the correct corner/edge pieces to use.
• 3. Draw "tall" layer. This is trees, mountains, someday walls and other stuff. It either does a 64x64 repeat like the blend tiles, or it has its own edge-detection system, a different algorithm from the blend one because it's matching like-to-like, not compositing priorities.

And then I cache the composited bitmaps with hashes. In the future I'll also cache the hashed results on the map, as right now when scrolling a lot of CPU is used to recalculate composites.

For the rest of the month I'm going to focus on some mechanics: chopping wood, mining, and building structures look easiest to expose now. As we reach the end, I'll look at doing NPCs or farming mechanics. That will probably make me go back and work on world generation some more.

[Triplefox]

http://dl.dropbox.com/u/254701/builds/blancmange/1_25_2011.swf

This build has some basic "chop wood" mechanic going. When you click somewhere the player will try to chop that tile down, but it will only work on trees. When chopping a countdown from 100 starts, it's slow right now cause I haven't tuned it, but when it hits 0 that tree is gone.

In the background I did these thingies:

• Collision detection(without a real broadphase yet)
• Changed motion from tweening to velocity-based so that you could "turn around" in the middle of a walk without it looking completely weird. This took a small pile of ugly code to resolve edge cases that caused breakage.
• Upgraded the tile caching code to store the hashed version of each tile's composite. Ugly to implement; I got some interesting-looking glitches while working on this(of the "tiles stuck in place/holes in the screen" variety), and it takes longer to start the game and do a save/load, but I think I've nailed all of the issues. But this was warranted because it made it more straightforward to update the tilemap, and it also lowers my CPU usage a ton(before, it recomposited everything every time the camera moved just to check to see if the same bitmap was used).

It will be straightforward to do mining after this, and with some UI and art effort, buildings. I also want to get in particle effects since those are always nice for player feedback.

[Chris Pavia]

Procedural world generation is great, looking forward to some gameplay!

Will there be other towns/kingdoms present in the world?

[Triplefox]

The amount of detail I put into outside civilization/monsters is the big thing I've left TBD. I'm going to start off with simple wildlife and bandits/marauders that set up camps and take your townspeople prisoner(no friendly deaths are planned in this game). Later I can do ruins to explore and more complex fortresses from the bandits. If all of that works, I'll add an endgame with one or more opposing towns that start on the other side of the map.

[Triplefox]

Coming soon: Peasant AI. They will do things for you. Shortly after that, other NPCs and combat should follow. It will start to feel like a game.

Behind the scenes: Wrote some code to efficiently handle the placement of the build/clear markers. Started putting together the GUI, and in doing so had to rework the way one clicked around the map(turned out to be a fairly trivial change, but it makes my old engine feature of being able to serialize listeners on scenegraph objects useless. Will probably remove that feature when I get over it.)

[Triplefox]

http://dl.dropbox.com/u/254701/builds/blancmange/2_3_2011.swf

So now you have 5 peasants, and they clear stuff. And you can build water - I decided to do instabuild instead of "mark-then-build" because it's easier to implement and more satisfying anyway. Also you can trap the peasants behind water and it shouldn't(cross fingers) destroy performance when the pathfinder cries about things being unreachable.

At the moment the peasants do not notice that you've put barriers in front of an existing path. I guess I will fix that at some point. For right now I am going to focus on building stuff other than water, growing crops, and particle effects instead of debug info when clearing stuff.

I should note that at this point I've felt a dramatic shift in the way the work feels - from the calm of pre-production to the hurricane of full-on development. This is approximately the point where inexperienced solo developers tend to get scared and abandon the project, because the design decisions start coming up very quickly and it takes tons of focus to tackle the important questions, carve out the "true game," and not get sidetracked in some bit of engine work or art concepting. Fortunately, this time I'm prepared with my "cycle model" of gameplay as a template for what the experience should be like when it's done. If I lash myself to that template and keep driving decisions based on it, I might have some chance of making a good game.

[Triplefox]

Progress:

• Character sprites in-game
• Particle effects when clearing terrain
• Building walls
• Non-functional guards(soon they will disperse to guard/patrol marked areas)
• Some improvements to the way markers work(islanding is handled correctly)

Yep, the gameplay's starting to come in.

I'd post a build or screenshots but this computer got hit with a horrible trojan and it screwed up Dropbox. Will reinstall everything tomorrow. The OS install is something like 1.5 years old now anyhow, it has way too much cruft.

[Triplefox]

http://www.magnategame.com/

The game officially has an official site. As well as the changes I mentioned in the last post, guards are working and will try to patrol through the marked areas. (They don't try to solve the travelling salesman problem to do so, I'm sorry to say.)

[Triplefox]

A small bumper for an upcoming big update on the 22nd(my "pre-GDC" demo), including:

• Some small graphical improvements
• World is shrunk to 128x128(more cozy than the 256x256 map, and better for performance)
• Destroyable monster nests that spawn equally destroyable creeps(who try to make their way towards friendly units).
• Friendly units, creeps and nests have "vision" boxes and use this info to enter combat or begin spawning.
• Combat: for right now, automatic projectile spam at the last target within vision.

Some last things I'm trying to get in by the 22nd:

• Some more graphics(all the new features have led to some asset requirements that I haven't fulfilled yet)
• Friendly units can be "killed" (at least, disabled.) The final mechanic will turn them into captives which the player can rescue.
• A few functionality/polish things involving creep invasion - things like them not walking through walls.

I'll have another build for GDC around the 27th or so. That'll probably be more polish, filling out features, etc.

[Triplefox]

Updated!

It is a very slightly playable game now. Albeit, you basically have no chance to "win" proudly, since the creeps spawn forever and your guards die too quickly and it takes too long to destroy nests. You could eventually conquer the map, though, if you die and respawn over and over.

The GDC build is going to focus on refining all of these things.

[Triplefox]

Update for GDC

• Build palette
• Markers can be removed now
• Fullscreen toggle button
• Some reworking of the gui's looks
• Idling units will try to unstack(aesthetic improvement)

It's getting more fun