Proto-RTS

[Geti]

This is a project me and a few other guys have been working on, but what you're seeing now is all my work.
I've finally got input working!

The aim is to produce a game that has RTS-style gameplay with very little micromanagement, that is mostly AI driven. Its more of an experiment than anything, but I thought I might as well share it, and get some exposure.

---------------------------------------------------------------------------------------------------------------------

If anyone is interested in a temporary position helping with terrain generation, optimising, spriting or whatever, be my guest. You'll get your name in the credits, its really all I can offer at this point in time.
Anyone wishing for a permanent position at Adrenaline Studios should contact me via personal message.

Current todo:

• -fix the cliff bug STOP PUTTING IT OFF ASfiwheguvjdsf
  -fix the team bug (prevents units from updating) >< >< --SORT OF DONE WORKAROUND ICK
  -implement grass and use the lovely grass sprites
  -Fix the movement bug
  -terrain evolution

Other Notes:

• -There are some rendering bugs
  -the units have some trouble following build orders
  -I'm still tinkering with everything so there'll likely be some bugs I've missed or weird tagging. That's all part of the fun, report any you notice though

Code: Select all

CHANGELOG: NEWER AT TOP
12/6/2010: New version 0.8d
	-added a version with embedded windows binaries for the lazies out there.
	-fixed the "random" bug ;)

10/6/2010: New version 0.8c
	-back to zip packaging
	-added boundary locking, no more flying off into nowhere with the map never to be seen again!

09/6/2010: New version 0.8b
	-stripped back dev files, repackaged with better compression -> tiny download

09/6/2010: New version 0.8a
	-Input System
	-Better GUI
	-Better AI
	-A million bugs fixed
	-Various tweaks

28/2/2010: New version 0.6
	-Refined job system - still not perfect/what I want, but works for tweaking behaviours.
	-Unit reproduction and base genetics - needs more modification
	-HUD updated.
	-more optimised drawing functions, should be _less_ hard on onboard/old chipsets.
	-building sprites

23/2/2010: New version 0.6
	-UNIT TASKS ADDED - needs class implementation and refining, but still
	-Resource system and hud rudimentarily implemented

14/2/2010: New version 0.5b
	-Fixed the lag issues, pathfinding is still a little gimped.

13/2/2010: New version 0.5a
	-units rudimentarily implemented
	-basic pathfinding - HORRIBLY LAGGY
	-Lots of tinkering, everything is now a lot nicer and faster except for units.

5/2/2010: New version 0.4
	-automaton now has grouped terrain (currently biased towards plains)
	-trees have update and destroy functions

1/2/2010: New version 0.3
	-again updated automaton
	-better vegetation system
	-more tiletypes
	-civ placement and terrain type readout at end of generation
	-a trillion new ideas
	-BUG: Cliff detection fail.
		-possibly related: random chunking around the edges of the map

25/1/2010: New version 0.2
	-much more advanced automaton
	-sprite based drawing of types and vegetation (way prettier)
	-beginnings of an entity system
	-dedicated 32 colour palette (!!!) per sprite, with 16bit overlays (modulation)

6/1/2010: New version 0.1
	-improved generation and load times :D
	-temporary altitude drawing mockup

Code: Select all

CREDITS:

	The Adrenaline Studios Team:

	Geti 		- Joint lead creative design, lead art, joint lead programming.
	Unussapiens 	- Joint lead programming, site hosting, enigma.
	Shikaze 	- Joint lead creative design.
	Altemo 		- Dreative design.

	Special Thanks:

	Arne "Prometheus" Janssan 	- Artistic inspiration and encouragement.
	Daniel "Data" Tabar 		- Design inspiration.
	LOVE Team			- Love2d Engine.
	Gurks				- Minimal conceptual design and sitting here
					  whilst I battled with the automaton bugs.
	Yar () 				- Basis for a lot of the terrain and vegetation sprites.
	osuf-oboys 			- Automaton ideas.
	Borsty 				- ISOLOVE example.

DOWNLOAD v0.8d drop.io

[bmelts]

Neat! You don't see a lot of isometric games anymore, but I always liked the style.

Also:

The aim is to produce a game that has RTS-style gameplay with very little micromanagement, that is mostly AI driven. Obviously, you will be able to direct the AI, but it wont be to the level of "this unit go there do this action".

This is a cool idea, and one that hasn't been used nearly enough imo. Have you ever played Majesty? It had a similar conceit: you could recruit heroes, build buildings, and do all that standard RTS stuff, but every hero had their own priorities for what to do, and the only way you had to direct them was through paying money into reward flags, that would give a payout to any heroes who attacked a certain unit/building, or explored a certain area (certain heroes required more "motivation" than others). Other than that, they would spend their time doing whatever they felt like, and you couldn't directly control them. (Every hero also had its own name, level, inventory, wallet, etc., so it was kind of like an RPG where you couldn't control the characters.)

Anyway. Majesty was awesome. Your concept sounds awesome. I look forward to seeing what comes out of this experiment!

[osuf oboys]

AI, procedural generation, and game-changing philosophies, awesome!

Sprites are all placeholders, and currently its only a world generation cellular automata and isometric viewer.

What do you mean by cellular auatomatons for world generation? I, here, interpret it as though a cell. automaton defines the altitude of tiles with the neighboring altitudes as input. You seem to set a random type (highland/lowland/...), a random height based on the type, and then averaging. I think the generation is so slow because of parts such as "avgActiveNeighbours(worldTable, v, 2)". Perhaps it would be better to index the altitutes by their location and only averaging neighboring tiles. Although I do not see any yet, I'm also not sure about the choice of cell. automatons for the generation in general. (although they are great for other things). If you do use them, perhaps relative altitudes as input instead of the absolute values will create a smoother and less random terrain, albeit hilly rather than flat.

Instead of using different images with variable tones, you could turn on the "modulate" color mode and use setColor before drawing the tile.

The first time you use a variable in a function, you should use e.g. "local worldTable = {}". This will ensure that it does not change a variable with the same name elsewhere.

Good job. Would love to see more.

[Robin]

For landscape generation, you may want to look into Fractals rather than cellular automatons. Those can be particularly well fit for landscape generation. I don't have a reference implementation at hand, unfortunately.

[Geti]

Hell yes, I wish I knew how to implement perlin noise and the like in Lua so I could work from there, but for now what I'm doing is generating nodes and repeatedly averaging and permutating, though I want to get more sophisticated soon, though probably after I've at least rudimentarily implemented units and structures, and probably vegetation.
I'm currently not very fussed about the speed of generation as maps are going to be fairly persistent (think dwarf fortress style, with many civilisations on the map), though I'm currently tossing up weather to do generation of a whole world in segments (ie the world can expand when you start a new game, if you start it in the same world) or just generate huge worlds from the get-go. However, if anyone wants to help out with optimising the averaging function or anything else, or adding more sophisticated feature augmentation (currently the highland and lowland augmentation is gimped), you're more than welcome. Anyone looking for a more permanent place in the development cycle of this game/experiment will be considered, especially since I can't get much work done over the next 3 weeks (I'm getting my restricted license and then going on a technology forum at some uni).

AI, procedural generation, and game-changing philosophies, awesome!

Hahah, that's the plan. Lua is great for AI, so love seemed pretty perfect. We'll see how it turns out.

Instead of using different images with variable tones, you could turn on the "modulate" color mode and use setColor before drawing the tile.

*facepalm* that would have been smart. As I said, they're just placeholders, I intend on having actual terrain textures eventually (more vars per tile..), but I might do that for now. I'll see if I can get it working.

Anyway. Majesty was awesome. Your concept sounds awesome. I look forward to seeing what comes out of this experiment!

I've heard it was before, someone brought it up as we were discussing the idea in person, though I'm planning on making it more along the lines of "expand that-a way" and "produce more of this gun/sword/axe/laser". I'll get more into that soon, have to run now.

Glad you're keen to see more

EDIT:

The first time you use a variable in a function, you should use e.g. "local worldTable = {}". This will ensure that it does not change a variable with the same name elsewhere.

Oh, i know, but for the worldTable it's used in the callbacks, as it's the active world table. I missed the node vars though, so thanks for that. Means i have to rewrite some of the functions a little but not too much.

Currently aim is hilly terrain that I can cut pieces out of for starting areas for main players (not wilderness/rebel civs though), feel free to slice and dice the automaton around to get the desired result, I'll be doing that a bit myself.

[Geti]

Bump, 0.1 version in OP.
I used relative generation and double averaging, currently i have to reimplement types (i'm currently thinking grass, dirt, stone, sand, snow, and water, as well as unique vegetation for each type), though I need to look into that more. I want it based on hight and contour, if anyone has ideas about implementing that hit me up.
I'm very happy with how its working now, I need some tile texture sprites though (cbf doing pixel art today, maybe tonight though if nothing turns up) if anyone feels like spamming some at me *hint hint*.

[osuf oboys]

Oh, I think the map generation produces a lot nicer results now and it is a bit faster. (Although the screenshot is pretty bland) There's a bug in the generation that is causing the diagonal ridges: #worldTable - x should be #worldTable - ecks, and you have to use y instead of x actually since you process y before x. I can see it, your maps will really be awesome with those terrain tiles, some water, and nice coconut tree.

Fractals are cool but I am personally not satisfied with their results; they are too random IMO. Some smoothing produces something decent but also removes features and makes something bland. I do not have any great alternatives though; my favorite is just to set altitude attraction points of varying scale (from high-level features to low-level ones) and interpolating intermediate altitudes in a soft non-linear function. Automatons seem more fun but for procedural generation, I personally like the general top-down approach from abstraction to detail.

love.system no longer exists. use love.event.push("q") and love.load().

Will you have different area types? Like hilly areas, flat plains, etc. The current system does not seem able to generate any step cliffs. I do not know what a good way to fix this would be. I would just use the old weight trick.

[Geti]

love.system no longer exists. use love.event.push("q") and love.load().

Thanks for that, forgot to change it <_<

Will you have different area types? Like hilly areas, flat plains, etc. The current system does not seem able to generate any step cliffs. I do not know what a good way to fix this would be. I would just use the old weight trick.

well, that's the plan. For now, i might implement types and vegetation before making the automaton for the actual contour smarter though, to keep it simple.

[Skasi]

Reminds me of two things:
Good RTS games! And geogen.

[Geti]

Wow, that gives me some ideas on how to do my generation. Cheers
Will be working on this quite hard over the next couple days, but my 2 weeks away have let me feature creep the hell out of this.
I've decided that to implement the building and unit system I'm going to keep it purely economic for now, with only HUB, HOUSE and FARMs available. I might start making actual AI for the little dudes at that point, but I'll leave military implementation for a while.
Anyone keen to do some sprites? I'll draft up what I want them to look like now actually.