Adventure Game Studio

---

INTRODUCTION

Three years ago I started my first project with AGS that wasn't a simple adventure - no, it was going to be a real-time strategy game. I didn't know all that much about programming back in the day, but the project got some pretty positive response (every now and then I still get a message about how it's doing), but in the end it came what had to come: I couldn't finish it.
      So much for the past - now I have decided to pick up the old horse again and take a good ride on her: it's back! But not only have I matured and learned in the meantime, AGS has done, too. Only with the more recent feature-additions of AGS 3.0 have I been able to build up the courage to give this another try. The feature list is similar, although I'm currently taking more influences from StarCraft as opposed to the heavy Command&Conquer-ness that was going on in the old version from 2005.
      I have a pretty decent working tech-demo pretty much done right now, which implements almost every single feature that is going to be in the game, so that's pretty good progress already done (I waited quite some time with this thread in order to keep the interested from having to wait for years - and to follow the forum-rules, of course). The majority of work now has to go into developing content (because if I learned one thing from my previous little doodad, Revelations, it's that a game can not appear well to a big audience if it's only technically impressive, it has to be a good game as well - well, duh, could've figured that one out myself in retrospect, but I guess I just didn't) - speaking of content, here is the list of features, which helps you to build your own picture up of how the game is going to look and feel like, it's followed by three screenshots to take the picture you just build up in your mind and rip it into pieces:


LIST OF FEATURES

• Build units and structures, select them, move them and let them attack - just like in most recent real-time strategy games (includes features like queuing build-commands for units, grouping units into teams using numbers 0-9, selecting units by drawing a rectangle and adding or removing single units by holding CTRL when clicking)...
  
• Use workers to gain resources to pay for new units, structures, upgrades and technology...
  
• Play against a computer-enemy that will hopefully act remotely intelligent...
  
• Get a quick overview of the battlefield on the radar-map, it not only shows you units and structures, but also the general shape of the terrain underneath them, so that you can successfully lead your troops through those narrow canyons...
  
• Different terrain-types, lots of different units and buildings (exact numbers are not clear yet)...
  
• Fog-of-War effect to make the game-play a lot more interesting...
  
• Music and sound-effects (format of music is not yet decided)...
  
• Editor to create own levels...
  

SCREENSHOTS (PARTIAL AND FULL SHOTS)

Newest:

Older:


Please keep in mind that nothing is final yet, that means the name might be different, there might be more than one resource, the graphics may change and - as you read above - the exact number of unit- and structure-types isn't yet fixed either. Please use this thread to comment and criticize constructively, tell me what you think, suggest units or technologies...

Not anything remotely constructive to say but:

YAY!!!!!!!!!!

This looks very very nice. Having seen your previous efforts at games which are NOT adventures, I know you can pull it off!

So the main advice: Stop school, leave your family and girlfriend, hook up with some serious food that will not need cooking, get some water by you side (around 10L) and sit to finish this game really really really really quickly!

CAUSE I WANT TO PLAY IT!

wow this was my dream of a project when i played for the first time command&conquer

great one and good luck :D

edit:
i hope it will not be a simple construct&destroy, but a real strategy game in wich you have to plain things

An RTS in AGS? A difficult project to create, I am sure, but perhaps further proof of the flexibility of the engine...

Best of luck - the screenshots and provided information look brilliant, and there is little doubt that this one has risen towards the top of my "AGS Games I Wish To Play" list.

Thanks a ton for the motivation so far! :)

I will be updating this thread with additional information, short essays or something regarding the development, new screenshots and maybe a tech-video showing progress so far.

Looks superb, very well done Jan!! Can't wait to give this a play! Let me know if you need any music. Now, get to it!!!1

Wow, this already looks super awesome. Good luck, and I hope you finish it.

Holy, shmoly! This looks fricken awesome! Can't wait for this one, man!

Glad to hear you picked it up again.


--Snake

Looks brilliant! Can't wait to play it!

I can't wait, it looks amazing! ;D

Heh, it was just few days ago when I read the old production thread for this game and thought, this could have been a good game.  And now you started to do it again!

It looks great! Good luck for finishing it!

Good show, good show!

That somehow reminds me of the original Dune. Brings a tear of nostalgy to me ole eyes... Best of luck for making this!

something like this better win for best programming next year

My god!

Best of luck to you, this is a truly awsome project.

Quote from: Da_Elf on Fri 08/02/2008 01:07:10
something like this better win for best programming next year

Only if Yahtzee doesn't rehash an old game again ;)

Thanks for the thumps-up so far. ;)

Okay, as promised, I want to keep you guys informed with brief essays or something - concerning the progress of development or technical details, just information that I deem interesting to share with you game-creators.


TECHNICAL ESSAY#1: The Radar-Map

This essay will explain the radar-map in the project. Now, you can already see it working in the screenshots in the first post, that means I've already implemented it and that's true (I didn't fake or photoshop it), but there's a slight problem with it: it tends to run slow.
      That's not something you wouldn't come across when you program a game like this, in fact, it'll always slow-down here and there. Too many time-expensive algorithms are necessary at every corner - all you need to do is find the bottle-necks and optimize the hell out of everything: try or invent tricks for improving performance - which might boil down to using smart math, like keeping away from too many trigonometry-functions (sin, cos, tan or similar) or too many square-roots, but sometimes more is necessary (some quick examples: frustum-culling, which means I don't draw any tiles that aren't on the screen at the moment, or just effective drawing, which, in my case, means I don't draw tiles that are in the fog anyways).
      But let's get back to the radar-map: it's easy to do a map like this with a simple background-color (roughly representing the terrain) and then to plot all units owned by the player green and all enemies red. But what I wanted was a map that actually showed you the terrain. As I put it in the text-part of my original announcement, I wanted the player to see all the objects and terrain-elements on the map (could be water, hills, cars, houses, slopes, canyons, you name it) that aren't traversable (at least by a unit on the ground, flying units are possible, not yet implemented though), so that he or she can plan the way he or she is going to take when commanding his or her units. This is not necessary (one could move the camera by placing the cursor close to the screen-edges or holding the cursor-keys down in order to find out a good way, but that wouldn't be very comfortable), but I wanted to take that problem from the player - plus, every recent real-time strategy title featured this. Additionally, if you imagine building a base in a safe corner, surrounded by steep slopes that are not traversable, you'll feel all safe and cozy - you'd probably want to see those barriers (and the respective openings that you'll have to block with your strongest units, because that's where you're gonna get attacked) on your map; how would it feel if the map didn't show that tactical situation?
      Okay, so I implemented this feature. And it ran slow, which is no wonder. The radar-map is 100x100 pixel sized. Every pixel on that map has to be checked against the "real" map, that means 10000 calls to a somewhat expensive function every frame. Runs at one or two fps, way, way too slow.
      Now, first I implemented a variable that determines the sharpness of the map. As you can see in the screen-shots, every pixel on the map-background that resembles terrain is actually 4x4 pixels big. This means four times less action and a much faster game. People with faster computers could up this variable to 1, which would give them pixel-clear radar-images, people with less computing power can change it to a higher value and run the game nicely, still.
      This works easily, but isn't beautiful, which is why I'm working on the best solution right now: since terrain is not destructible, I'll load the map into memory (array) and not recalculate it at all. I'll report back when I have that working...

Sound like something I couldn't get to work -- ever.

Great work. I hope you won't get too frustrated with it. I'd really like to play this game.

I'm utterly happy to see this project launched again. :) Good luck with it!

Quote from: SSH on Fri 08/02/2008 12:31:03

Quote from: Da_Elf on Fri 08/02/2008 01:07:10
something like this better win for best programming next year

Only if Yahtzee doesn't rehash an old game again ;)

Hey, no spoilers!! lol

Thanks, your interest in this project is much appreciated!

TECHNICAL ESSAY #2: Pathfinding

This is the only problem I'm having right now, although I can calm you down by saying that it's not that bad - I have it working in an at least playable state right now already and I might be able to (it's gonna be hard though) solve this after all.
      Okay, so I have units and I can move them, but they won't move smartly. If I have one or more units in location A and want them to move to location B - where A and B are separated by a body of water or a steep slope or maybe even a building or another unit - they'll move to the edge and stop there. What they should do is what is called "pathfinding" - they should find a way around the obstacle and take that route. That's not always perfect either, as that path might lead right through an enemy army, outpost or base, but that's just how most recent real-time strategy games work.
      AGS has implemented pathfinding for characters nicely as you developers probably know, so no user has to really worry about the somewhat complicated world of A*-algorithms and the like. There are reasons, however, why I can not use these already implemented solutions: first of all the project doesn't use characters to display units (that would not be suited at all), it uses the dynamic sprites in order to theoretically display millions of them, second of all, pathfinding in real-time strategy games is different from pathfinding in adventure games.
      Let me clarify that last bit: while it's sufficient to use one algorithm in an adventure game where only very few characters are moved around simultaneously, almost all real-time strategy games use several methods (one for short distance, one that is somewhat less fine but faster for more units over longer distances, etc).
      Anyways, back to the project. Using the implemented pathfinding-routines in AGS won't be possible, if I'm not mistaken, so there are two options: implement your own or just make the user define the paths himself. The former is hard to do and will most likely slow the game down a whole lot (maybe it's worth a try if I have enough time, though - I could try to optimize this; for example when moving a lot of units, only give the first twenty units the order to move, so the game doesn't slow down as much, then give the next twenty the order one frame later etc.) and the latter is what I'm doing right now - it works, but it isn't not all that comfortable. I guess I'll see.

Little update: I have finished including shadows and air-units. This turned out really nice, actually. Take a look at this excerpt from a show-off shot:


It doesn't only look nice and adds a feel of depth, it also works very ergonomically - drawing these shadows doesn't require any new artwork or anything, the volume is created on-the-fly with a second dynamic sprite, the tint-functions and the possibility to draw images with transparency. Shadows "stack up" at the moment (when they overlap, that part of the shadow gets even darker) which is not really realistic, I think, but it actually looks nice and fine to me and flying units even throw shadows on ground units and buildings which is very important to create that sense of height and depth.

As I mentioned, it allows units to fly (well, it only shows they're flying if there's a shadow) - the units actually move up or down a bit every now and then as you might have noticed they do in games such as StarCraft to emphasize their height and how they hover.

Of course, flying units will not collide with stuff on the ground (terrain stuff such as slopes or trees and bushes) or units and buildings on the ground, however they still collide with other flying units - logically.

I will actually allow players to either turn shadows off (for slower machines, should increase performance when controlling lots of units), make them absolutely black (which will be slower than the previously mentioned option, but at least a bit faster since the game doesn't have to draw the shadows with transparency) or to have them look realistic (which is what you see in the shot above, the slowest but best looking option). Shadows aren't that expensive, though, on my somewhat dated machine (P4 ~2.5GHz, 6 years old) they don't slow down that much in comparison.

What do you think? Any other ideas for effects or functionality? Do the shadows seem good to you? Any feedback is appreciated as always. :)

You do know that I will make this whole thread into a PDF once you're done, right?! :D These notes need to be documented!

What are your thoughts on sound/music? Cause I might have an idea... (to PM ONLY!)

I'm so happy you've revived this! If it's anything like Starcraft or Warcraft II, I'll be hooked for a long, long time.

Little update: I have been able to get some work done on the following aspects...

• improved radar-map (see first technical essay for information) - put short, it's not as blocky as the screens anymore, it works pixel-perfect for both units and terrain and it works faster...
  
  
• improved unit-movement - through a series of rather complex algorithms, units now move better in groups and shouldn't get stuck in each other or anything, this helps a lot in-game...
  
  
• units can idle now - every now and then (semi-random interval) they'll look to the left or right a little bit (they won't make a 180° turn for example, that doesn't look good, it's fixed to a maximum degree left/right, so they only move a little - they could make several full turns if you wait long enough though)...
  
  
• units can actually die now - well, currently they just disappear - I still have to think about how to realize explosions (or similar)...
  
  
• added some variation for the desert ground-tile - it looks a lot better now, no comparison to the old look at all, you'll see the difference in the next shot; when a level is drawn in the editor, the desert ground is calculated automatically and varied randomly, still (similar to the editor in StarCraft) you can change the look of single tiles if you want to force them to be one special variation...
  
  
• money- or resource-counter (right upper corner of the screen) now dynamically counts the money; when you gain "credits" it doesn't just show the new amount instantly but blends to that number by counting through the difference - for example the player starts out with 500 "credits" for testing purposes at the moment, when the game begins, the counter starts at 0 and quickly counts up to 500 and when the player builds a tank (costing 200 right now), it doesn't instantly subtract that amount but rather count down in like two seconds.
  
  
• started developing the editor - it can create new maps, load, edit and save maps which can be loaded by the main project already, eventually this will allow me to create more complex maps with more terrain-types, objects and little doodads.
  

That's the progress so far - concerning your questions about game-play, I'm able to tell you that I probably won't be able to add a real campaign (with scripted events etc.), because that would be very hard to store in the level-files, it's probably going to boil down to combat-mode only (you choose a map and play against one or more enemies) although it's possible that a simple campaign will exist in which you battle against an increasing number of increasingly good AIs (no guaranty though).

I can't promise that it'll play like StarCraft, Dune 2, WarCraft 3 or C&C 1 or any other part of the series for various reasons (pathfinding, complexity of tech-tree, application-speed etc.) just as you won't expect a common adventure made with AGS to play and feel exactly like a great top-notch commercial adventure-game such as Monkey Island 1 or DotT, but the core-elements are there and I'll try to make the best game out of the technical features that I can.

Once I have more features to show-off I might create a trailer-movie or something. I'm thinking about that because it could show off some of the work in real-time and some effects really don't show in static pictures.

That's great man! :D

I'm happy that this is still alive and well.

Wintermute has an interesting pathfinder algorithm. Basically, the pathfinder tries to find a straight line path. If it is blocked, it then goes through a list of author-programmed waypoints: if there's a path from a waypoint to the destination and a path from the current position to a waypoint, then it simply does two straight lines. (It also works out the shortest path if there are multiple waypoints it could use). You can then take the algorithm further using a standard graph searching algorithm like Dijkstra's. Probably the best way is to:

1. Check if straight line path possible from A to B
2. If not, calculate the cost from A to every waypoint and B to every waypoint, in a straight line. Add these to the predfined wieghted graph of waypoints. If there is a blockage, then the cost is infinite...
3. Do a Djikstra on the graph to get the shortest route from A to B.

This would be reasonably efficient for a smallish number of waypoints, provided you can take the time to set them up on each map.

EDIT:  At the time of writing, I failed to notice that the radar had been fixed already:

Quote
improved radar-map (see first technical essay for information) - put short, it's not as blocky as the screens anymore, it works pixel-perfect for both units and terrain and it works faster...

My bad.

ORIGINAL POST:

Quote from: dkh on Fri 08/02/2008 21:09:52

      Okay, so I implemented this feature. And it ran slow, which is no wonder. The radar-map is 100x100 pixel sized. Every pixel on that map has to be checked against the "real" map, that means 10000 calls to a somewhat expensive function every frame. Runs at one or two fps, way, way too slow.
     

Are you sure you need to check every pixel on the map each frame?  It sounds like it would make more sense to only have the algorithm check the pixels which are within the players visible range.  Although, the only way I can think of doing that would involve writing 10000 'if' statements under the 'repeatedly execute' event.   :-X

Maybe something along the lines of:

//***--VISIBILITY TEST--***
//Tests all pixels, identified with values from 0-9999, for whether they're visible.

expensive function(int ID_pixel);  //Let's pretend this is the declaration of your "expensive function" mentioned 
                                                     //above.

int pixel = 0;              //Identifying value of the pixel being tested.
bool visible[10000];  //Has the visibility status of a pixel stored (thanks to a separate function).

while (pixel !=10000)  //Keep testing until the 9999th pixel has been tested
{
     if (visible[pixel] == true)
     {
          expensive_function(pixel);
     }
     pixel = pixel + 1;  //Test the next pixel
}
     


You'd still be stuck with 10000 calls by one loop, but at least only a handful of those calls would have to deal with the "expensive function."  I hope that wasn't insultingly useless of me to mention!   :-X

You're cool man! That's awesome!  :)

It is fascinated, what the AGS "adventure" engine can be used for.  ;)

Weeh, the thread was kicked off the front-page but came back, thanks a lot for that, guys! :)

Anyways, here's a new screenshot, notice the variety in the desert-tiles and the shadows, also, the flying units now have fire coming out of their thrusts when they move:


@HammerBlade: the problem with your suggestion (if I'm understanding it correctly) is that the radar-map has to be updated for the whole map and not only for what the player sees. Especially when units move around that are NOT in the player's view, it should show that movement on the radar-map. If you meant something else, do not hesitate to respond and clarify, please, I'm always open for ideas and I'm sure that I'm not yet doing everything in the best and most effective way.

@SSH: that's interesting and will definitely come in very handy once I try my hand at implementing the path-finder. I'm still concerned that it will run really slow though, but, as I said, the only way of finding that out is implementing and checking. At the moment, I also have another solution: I could allow the player to manually "draw" paths that the units will follow. This is not as good as a real pathfinder, but somewhat of a compromise. I'll try all different solutions out later in development.

Man, that looks friggin' great!
I can only imagine the insane amount of hardcore scripting that went into this so far.

About the map: from what you've written, I gather you're doing something similar to a raytrace. (If you don't, skip over the next paragraph ;))

Thinking about it, I came up with this solution: draw the map while drawing the main screen. Iterate over the whole map, and while skipping visited tiles that are off the screen, draw a light pixel for ground and a dark one for obstacles.
Then iterate through the units and do just the same: paint a pixel on the map for every visible unit. The cost of that should be an additional next-to-nothing.

Thinking about it some more, I had another idea: Since the map is static, draw it using three steps:
1. draw a sprite that's generated once from the level data, showing the complete map.
2. draw the units on top by iterating through them and placing the pixels at their respective map positions
3. draw another sprite on top to add the fog of war. This sprite starts out all black, is kept in memory and updated with transparent pixels whenever the player "removes" the fog of war in the game.
If the map isn't static, you only have to update a few pixels in the original map sprite. This shouldn't happen often, so again, the cost is pretty much zero.

To improve trigonometric performance, use an array holding e.g. sin(0.01) to sin(1.57).
Then derive cos and tan. Reading a variable should be several times faster than calculating a trigonometric function.

EDIT:
I've just taken a closer look at your screenshots and realised that your tiles are 25x25 while your map uses 4x4 tiles! That's unusual but luckily doesn't invalidate the suggestions I made. :)

Quote from: dkh on Tue 19/02/2008 13:41:58
the problem with your suggestion (if I'm understanding it correctly) is that the radar-map has to be updated for the whole map and not only for what the player sees. Especially when units move around that are NOT in the player's view, it should show that movement on the radar-map. If you meant something else, do not hesitate to respond and clarify, please, I'm always open for ideas and I'm sure that I'm not yet doing everything in the best and most effective way.

When you say "what the player sees," you're referring exclusively to the main screen and NOT the radar at all, correct?

So are you saying there's no corresponding fog of war on the radar to that which is on the screen?  If so then yeah, what I suggested doesn't make sense at all.  However, if fog of war does show up on the radar, then I still meant exactly what I suggested.  My point is that, if the player can't see that the enemy is moving about on the radar, why waste resources updating that visual radar data to begin with? 

In any case, Khris's suggestion makes a ga-jillion times more sense than mine, so I guess it's a moot point.

Quote from: KhrisMUC on Wed 20/02/2008 16:56:22
Since the map is static, draw it using three steps:
1. draw a sprite that's generated once from the level data, showing the complete map.
2. draw the units on top by iterating through them and placing the pixels at their respective map positions
3. draw another sprite on top to add the fog of war. This sprite starts out all black, is kept in memory and updated with transparent pixels whenever the player "removes" the fog of war in the game.
If the map isn't static, you only have to update a few pixels in the original map sprite. This shouldn't happen often, so again, the cost is pretty much zero.

That's exactly what I'm doing right now (for the latest screenshot, step 3 was commented out, that's all). :) The rest is already working in this way and really not a bottleneck for slow-downs anymore.

Quote from: KhrisMUC on Wed 20/02/2008 16:56:22
To improve trigonometric performance, use an array holding e.g. sin(0.01) to sin(1.57).
Then derive cos and tan. Reading a variable should be several times faster than calculating a trigonometric function.

Luckily, I get around without using trig-functions. What I'm doing is more like look-up tables than raytracing.

Quote from: KhrisMUC on Wed 20/02/2008 16:56:22
I've just taken a closer look at your screenshots and realised that your tiles are 25x25 while your map uses 4x4 tiles! That's unusual but luckily doesn't invalidate the suggestions I made. :)

That's the old screens (back when I had a "resolution" for the radar-map), at the moment I have 25x25 sized tiles on the main screen and I pick a background color on the radar-map for every single pixel on the map (100x100 pixels).

@HammerBlade:

I think I got what you mean, now. Fog-of-war does show up on the radar, but the background of the radar-map is always going to be drawn, because it's non-static, without recalculation, which is very, very fast. The units are really quick to plot as well, so I think it's actually faster to just iterate through existing ones and draw that pixel than it is to check for each one, whether it's under fog-of-war or not... That last part is what you meant, right?

Thanks for the feedback, everybody!

Quote
I think I got what you mean, now. Fog-of-war does show up on the radar, but the background of the radar-map is always going to be drawn, because it's non-static, without recalculation, which is very, very fast. The units are really quick to plot as well, so I think it's actually faster to just iterate through existing ones and draw that pixel than it is to check for each one, whether it's under fog-of-war or not... That last part is what you meant, right?

Yes, that is what I was referring to.  Well, if the units draw fast enough to justify checking each pixel for where units are on the map and drawing them, then I guess it'd be more trouble than it's worth to do an additional check for whether units are hidden by fog of war or not. 

Exactly. I'll investigate that, though. Thanks for the food-for-thought! ;)

Little update: I'm currently working on a better shadow-system. If it fails, I still have the old one to fall back to (which was working and looking just fine already). What I'm trying to accomplish is getting rid of that shadow-overlapping-phenomenon - if two or more shadows overlapped each other with the old shadow-system, the overlapping part would be drawn even darker. That's not realistic, if shadows from one light (sun) overlap each other, they are not "added up".
      So, the new system basically consists of one empty dynamic-sprite that covers the whole screen. Every unit then draws its shadow (as long as its actually on the screen, of course) onto that sprite, which is then tinted to look like shadow and drawn. This way, if two shadows overlap, the overlapping part should be exactly as dark as the single shadows are etc. It's not there all the way, yet, but I'm pretty sure I'll manage to get it to work properly these next days.
      Also, I have changed the colors of the selection-marks, the health-bar and the selection-rectangle (which you draw to select multiple units), I wasn't satisfied with that bright-almost-white-look, they are now dark grayish, parts are almost black, plus the healthbar over selected units looks a bit "rounded" now. I don't want to post another screenshot this soon, but I'll make sure to show it off in the next image-material.
      Last but not least, I have started improving some sprites, the factory-building you can see on almost all screens looks better now.  You can see it has changed from the oldest screenshots to that newer one. Now it has changed even more, though slightly. I'll try to not only add new, but also improve existing artwork until it all looks as good as I think it should, even if it takes a lot of passes on some stuff.

And it is really from AGS??? Unbeliveable!!! :o ;D :o

Hehe, thanks, Mirek CZ!

I thought I'd give you another update on how progress is going. With all the game-in-production-activity going on at the moment, if you don't have any news for 30 days, you're pretty much on the third or fourth page... ;) (Not that I don't welcome all the productivity though).

Little update:

I haven't been able to do very much in the last months, but I did introduce a new unit, the marine (or trooper) so far and I can also show you the new color-scheme for the selection-marks and -rectangle:


I'm currently thinking about rewriting parts of the GUI system (mainly the part that has to do with the six buttons on the lower-right corner of the screen, the part that allows you to build new units and structures if you have a worker or a facility selected and cast "spells" - I put that in quotation-marks because there won't be magic-spells in the game, as in, real magic, that's just a technical term for special abilities/weapons, for example a unit could send an emp-shockwave every now and then etc).

I'm also thinking about a way on how to handle the creation of units. At the moment, if you queue up 3 workers to be built in a factory, it will build the first and spawn it directly in front of the building, then if the second one is ready it will try to spawn it and if that space is occupied, it won't spawn it and leave a message. I'll have to implement a simple system that tries to find a spot that is yet unoccupied and the closest to the factory. So it will create new units around the building and if it's surrounded entirely it will start spawning units a little further away, etc. It's not that hard, but a little annoying to implement if you don't fix your unit positions to tiles (like some games did) but rather have them move around freely anywhere (like for example StarCraft does, most notably in the editor, StarEdit, when you place a unit you can't really place it anywhere you want, not only on tile (5,8) and then it jumps left a tile for example to (4,8)).

Um, totally missed this thread, but just wanted to say:

CHRIST! You're kidding right? RTS in AGS? If I could send you a beer by e-mail, I would!
From the screenshots it looks very Dune 2-like, which I think is great.

Quote from: dkh on Sun 13/04/2008 13:17:08
I'll have to implement a simple system that tries to find a spot that is yet unoccupied and the closest to the factory.

What about moving the first soldier after it's created so it's out of the way?

No pressure intended, but get a demo out soon!

Just a suggestion. I apologize if you've mentioned this somewhere.

Are you adding hotkeys as well? Or is it all point and click?

Also, the new color scheme for selecting units looks nice, and the addition of a trooper unit is nice as well. :)

Keep it up dkh.  ;)

I've played a few RTSs before Starcraft etc. and I constantly annoyed by enemy AI. I know it's very hard to program without constant feedback by real humans on how to implement battle strategy. I'm no expert but I know one thing that would make your game stand out.
The thing I'm talking about is the AI's view of the board.
If you want the game to be good you should program in a fog of war view into the AI. In most games AI looks at whatever's on the board and goes for the biggest threat to him this works basically but is unfair to the player as they cannot see the whole board at once. What I propose is hard but not impossible.
I propose that you give the AI a feature that mimics human viability and also has the AI use a random path each time to discover more of the map as he progresses making conclusions depending on what he can see. Such as  if he can see enemy units he'll either chase after them in that direction dumbly if hes set to an easy level or he'll try to plan a strategy based on how much he can see of the enemy units or bases. This will make the game far  better than some other that use the aforementioned method.             

Thanks for the feedback, guys.

Quote

Quote from: dkh on Sun 13/04/2008 13:17:08
I'll have to implement a simple system that tries to find a spot that is yet unoccupied and the closest to the factory.

What about moving the first soldier after it's created so it's out of the way?

Well, then I'll still have to find a spot for the unit to move to... :) I'll see what I can do, though. It's no biggie.

Quote
Are you adding hotkeys as well? Or is it all point and click?

There will be hotkeys. At the moment, grouping units is already supported (select a bunch of them by drawing a selection-rectangle, then hit CTRL plus a number and they will be grouped, a small number next to the unit, if selected, will indicate the membership; pressing a number selects that unit or group of units). There will most likely also be hotkeys for build-commands etc.

dirk delshire: Yep, AI is very important in RTS games, however I'm really not that far yet. I think it's going to be one of the hardest tasks to realize.

Just a tiny little update to show that there is still some progress.


The tank is back on the ground where it belongs, and a new real air unit is implemented. At the moment it functions as scout mostly (fast moving air-unit with little damage), but that function will most likely soon be taken by a dedicated, smaller scout-unit that actually looks more like a scout. The unit above will then most likely be transformed into a heavy air-unit, maybe an air-superiority fighter or something along these lines.

Concerning the unit-design, I have now finally designed to go the "Blizzard"-route where every unit will be counter-able. Some examples:


Unit Name       Position        Countered by    Additional Notes
--------------------------------------------------------------------------------
Worker          Ground          N/A             Unarmed, builds new buildings, gathers resources
Marine          Ground          Bike            First fighting unit player can build, cheap, harmless alone, dangerous in groups, can hit both ground- and air-units
Bike            Ground          Tank/Air        Very fast, moderate damage, good against marines, can only hit ground-units
Tank            Ground          Marine Mass/Air Expensive, slow, high damage (with splash), good against bikes/buildings, can only hit ground-units
Heli            Air             Marine          Fast, little damage, good against Tanks/Bikes, can hit both ground- and air-units


Or, put in a graphical way and showing the way it's going to be soon, I guess:

I'm having an orgasm.

It seems like original DUNE 2, and I loved.

My best wishes to your game.

I'nt know if your are already making this, but you have thinked in merge the RTS with adventure-like scenes? (As interactive cut-scenes to make trougth the military campaign)

Or campaing-map with enemy territory selection?

That was incredible!

Go forth!

I feel the "paper, scissors, rock" idea (as I've heard it called) is a very good route to take - certainly makes sense and helps balance gameplay. A quick few questions from my end:

How exactly are you planning to implement this? Will it simply be a case of the weapon doing more damage? Generally, I think unit speed could come into play here as well - perhaps the tank might do more damage against a bike, but if the bike has longer range and can move faster, a tank will not be able to touch him (I recall certain Starcraft matches in which I was able to take out hordes of zealots with just a few dragoons simply because the zealots hadn't been upgraded and I could move so much faster).

With the case of marines being more effective in groups, is this just because of numbers superiority? And will you balance costs of units to show this? Say for example, a tank by itself can take out up to 5 marines max - will a tank then cost the same as 5 marines? It seems to be a very fine thing to get balanced correctly - If a tank can take out 5 marines, but costs the same as 4 marines, who is going to be building marines? If a tank costs the same as 5 marines, how will you calculate the helicopters costs?

Things like this seem to me to complicate the balance necessary for a standout RTS, or we'll just all tank rush one unit and be done with it  :-\.

The game looks and sounds great, and I do not mean to deter you at all - I'm just very interested in the "how"s of what you're working with.

Quote from: Alarconte on Wed 14/05/2008 04:21:45
I'm having an orgasm.
It seems like original DUNE 2, and I loved.
My best wishes to your game.
Go forth!

Thanks, will do. :) By the way, I've not played very much of Dune (maybe first 2-3 scenarios), so I can't promise that it'll be very similar apart from the graphics (which mostly appear similar because of the strict top-down perspective and the sand-tiles which most of my screens are on).

Quote from: Alarconte on Wed 14/05/2008 04:21:45
I'nt know if your are already making this, but you have thinked in merge the RTS with adventure-like scenes? (As interactive cut-scenes to make trougth the military campaign)
Or campaing-map with enemy territory selection?

The story-mode is still undesigned. I'll think about different ways of implementing it. It might be a simple picture-background with scrolling text (DUNE-like), might be briefing-rooms (StarCraft-like) and it might be video-sequences (C&C-like) or a combination. Mixing RTS with adventure elements is unlikely at the moment, nice idea though, might be something for a next game with the "engine"... :)

Quote from: Ben304 on Wed 14/05/2008 04:53:08
The game looks and sounds great, and I do not mean to deter you at all - I'm just very interested in the "how"s of what you're working with.

Thanks for the feedback, you're not deterring at all. I appreciate your thoughts and they help me get a clearer picture of what I'm trying to do here too! :)

Quote from: Ben304 on Wed 14/05/2008 04:53:08
How exactly are you planning to implement this? Will it simply be a case of the weapon doing more damage? [...]

Yeah, this is a very important part of the game. The rock-paper-scissors-scheme (by the way, there might be a few more units around that scheme to make it a little less obvious) will be implemented by these unit-factors:

* Damage (as you said)
* Attack frequency
* Moving speed (as you said)
* Attack abilities (ground only/air only/both)
* Price and build-time
* Attack range (some units shoot further etc., there might also be minimal ranges for some units, tank for example)

Let's take your example of one tank vs. a group of marines. Now, first of all, this is very micro (short for micromanagement, meaning: having exact control over your units, like in an action-game almost) comes into play. With bad micro, you would have all your marines (take 4-5) in one group very close to each other approach the tank. The tank would fire and kill most marines (due to splash-damage) with the first shot. Say two marines survive with half hitpoints, they'll be able to come into gun-range and fire a bunch of rounds damaging the tank slightly until the slow-reloading tank fires again and possibly again and that's it. Not much danger there.
If we go through that again, with good micro this time, the attacking player would attack the tank either from multiple angles or simply spread the marines out a bit so they are not running/standing next to each other, this time the tank could only hit one marine at a time. The attacking player would not attack until the marines a very close to the tank, so close that it can't hit the marines anymore due to the minimal attack range. The marines now have a good chance of killing the tank.

Another, shorter example, marines versus the bikes. With bad micro, the bikes would engage the marines in a standing position, without making use of their phenomenal speed. Still, the bikes are infantry-killers, but if there are enough marines and few enough bikes, they might at least take some serious damage. Good micro would mean exactly what you describe in your post (where good StarCraft players will kill zealots with goons simply be letting them shoot once and then move away, because they are faster as long as the zeals are not upgraded), so the bikes would shoot and then quickly move a few tiles away, only to hit again quick, reloading on the way.

If all the factors above are not enough to ensure that the system works, I will also include a damage-type. Much like in StarCraft, there would be "normal", "concussion" and "explosive". Weapons with "normal" damage would give 100% against all units, "concussion" means 100% against small units (marines, workers) and only 50-75% against bigger ones and "explosive" means only 50-75% against smaller units and 100% against bigger ones. Tanks would have explosive damage, meaning big units (bikes, buildings, other tanks etc.) take full damage, but marines (small units) for example would not be damaged as much, in fact they might survive one hit, making them even more dangerous. Bikes would get "concussion" damage, dealing full damage against infantry, but not nearly as much against tanks/buildings etc.

It's my ultimate target gameplay-wise to not allow successful massing-one-unit-strategies.

This is the plan so far. :)

Again, thanks for the continuing feedback, that's very inspiring - keep it coming!

Excellent reply - you've clearly thought this through very clearly. :)

Micromanagement and having it as an essential part of the gameplay is an interesting thing - I find it can deter new players, but on the flip side it does add a lot of longevity to a game as players try to find new strategies/master established strategies. After playing Revelation, which I found difficult first but very enjoyable once I had the hang of it (and sadly short[yeah, level editor, I know]), I'd say this is not a bad thing.

The idea of the different types of damage covers how you can help specify the units a unit is effective against, which is excellent. I never took into the consideration that you could use this sort of thing against buildings to define your primary base destroyers (silly of me, I know) so it sounds to me that all bases are covered.

I am just very glad that I am not the one trying to program this ;)

Good work thus far, good luck for the continued development, and consider me one who is rather excited about this project of yours :).

By the way, the graphics look excellent, good stuff!

Quote from: Ben304 on Thu 15/05/2008 03:53:47
Micromanagement and having it as an essential part of the gameplay is an interesting thing - I find it can deter new players, but on the flip side it does add a lot of longevity to a game as players try to find new strategies/master established strategies.

That's absolutely true, I find it's best described by Blizzards game philosophy of making their titles easy to play, hard to master. This effectively means what you said there above - that you don't HAVE to micromanage your units in the most effective way in order to win, but once you start playing the game a little more, you actually notice the advantage you get from doing so.

Quote from: Ben304 on Thu 15/05/2008 03:53:47
After playing Revelation, which I found difficult first but very enjoyable once I had the hang of it (and sadly short[yeah, level editor, I know]), I'd say this is not a bad thing.

Heh, awesome, another one to play the game. :) Yep, it's real short unfortunately, I'm planning a second version though...

Quote from: Ben304 on Thu 15/05/2008 03:53:47
The idea of the different types of damage covers how you can help specify the units a unit is effective against, which is excellent. I never took into the consideration that you could use this sort of thing against buildings to define your primary base destroyers (silly of me, I know) so it sounds to me that all bases are covered.
I am just very glad that I am not the one trying to program this ;)

That part isn't all that hard actually, I define an enum eDamageType which contains all three possible states and an enum eUnitSize which contains all possible sizes (big, medium, small for example), then assign both enums as variable to each unit, set it according to what unit the instance actually is (on init of unit, a tank for instance gets the medium-size and explosive-type or whatever) and then, in the unit-function that handles dealing damage, I divide the damage-total according to the units that shoot/get hit. :)

Quote from: Ben304 on Thu 15/05/2008 03:53:47
Good work thus far, good luck for the continued development, and consider me one who is rather excited about this project of yours :).
By the way, the graphics look excellent, good stuff!

Thanks!

looking good, and sounds good.

but don't forget to add some trees - bushes - cliffs - water - civil buildings - car wrecks etc. on the maps.

Many freeware rts games forget those things and are then really ugly to look at.

i wish you luck how ever..

@23-down: Heh, thanks a lot for the feedback. The maps are probably the thing that's (graphically speaking) the most behind. I will add lots of stuff there, I will redo the cliffs and add objects (houses, holes, you name it), possibly water and similar stuff, don't worry!

Graphical update:

The old GUI that you were able to see in most old screenshots was never made to stay, really, so I used the last days to whip up a new design in Paint. It's not yet implemented, just a mock-up so far, but I don't want to keep this from you:


Note that the middle part of the interface (the black space below the currently selected unit's class-name) is not filled yet, I'm still working out ways of how to display the unit's health (better called hitpoints) etc., I like those green wireframes from StarCraft, but I don't want to copy just ANYTHING from there, in fact, I really want to stay away from it as much as possible right now. If anybody has any ideas, I'm all ears. Also, I'll use the space to show possible upgrade-levels etc.
Also note that the resource-icons (currently blue and green minerals) will definitely still change once the actual in-game resources are decided and set in stone.
Oh, the cursor is updated as well and the new GUI effectively takes exactly 60px away from the on-screen battlefield which should raise the frame-rates slightly! :)

Additionally, I can announce that in the near future, I will be able to launch some more news and insight about the different races, (in addition on the former) the story,
the resources (and how to gather them) and additional information on the game-play. And the name of the game is finally going to be changed once the story is established (because I'd like the title to actually reflect the story a bit if possible). Stay tuned and let me know what you think of the GUI.