5010 Light and Music

Trivial thoughts

Mon, 21 Apr 2008 12:22:28 GMT

Just an idea for a single-player trivia game based on knowledge about DM. Other than that, nothing extraordinary.

Test your knowledge of coding in DM

Choose from categories
Get next question, code snippet, screenshot, etc, and some multiple choice or true/false questions.
Pick the answer

If you are right:
You get points added to your score.

If you are wrong:
You get an explanation why.

The game would refer to a forum where questions are submitted and/or answers are disputed. This would allow the dream maker community to come up with interesting content.

Some desired features

remembers what you've answered so when you play again you can choose only unseen content or stuff previously answered wrong.
posts username and score on web (if you don't like it, play again)
a limited time for full points, like those trivia questions in bars

Development

Via DM: could be done with just skins. No need for map.
Via web forms: dunno how to do something like this, but there are examples all over the place.

My opinion

Could be a way for developers to check themselves for holes in learning.
Just because you score high doesn't mean you are expert coder.
I wonder if the scoring might be ammo for flame wars between developers. That would not be good.

Questions
Has anyone tried this before?

Your thoughts?

Splategy: mini update

Fri, 18 Apr 2008 22:00:58 GMT

Progress:

prioqueue: found and fixed insert bug at last node
astar: found and fixed g() and h() bugs
astar: check unit now facing correctly in order to squeeze thru tight diagonals
astar: cancel implemented and tested, selecting a new destination before the path is found aborts the astar before starting a new one

Known problems:
None! (yeah!!!)

Next steps:

redo closed list (no need for priority, what was I thinking?)
change test map for more pathing scenarios
test like crazy!
remove superfluous code and spam
test again for good measure
implement resulting path
move the unit!

However, if I get to ADD to stay on above tasks, I may break from it to make some music ;)

Splategy Mini-Update

Wed, 16 Apr 2008 21:25:54 GMT

Progress:

prioqueue: reimplemented without terminator node
A*: reversed to go from objective to unit, since the result is path back to the beginning
A*: encapsulated inside a new mind object
turf/floor/Click: switch direct astar call to objective notification to unit
new object: brain, which manages minds
units now have a brain

Known path problems:

check unit isn't facing the right direction, so it can't squeeze thru tight orthographic diagonals
need to increase g() slightly for diagonal moves to prevent a small quirk in path
need to implement astar cancel

Next steps:
fix the problems, test until no probs, then turn attention to custom walking to follow path.

Screenshot: A* testing, ? symbols mark turfs in the open list. blue boxes mark turfs in the closed list.

Splattering thoughts

Wed, 16 Apr 2008 12:53:21 GMT

Just jotting down some thoughts. Comments welcome.

Current implementation focus
I was thinking about Splategy's A* development. When you tell a unit the next objective, it calls a proc to analyze the map for the shortest path to it. The analysis does some sleeping along the way so that an impossible path on a large map won't lag the game, just the unit.

The problem
So what if you change your mind and choose another objective while it is still analyzing? You get wasted server processing, wasted resources, and object confusion.

The idea
I'm considering the A* running from an object proc. That allows each unit to keep track of their pathfinding in parallel. That makes a cancel proc possible, which would check a running flag, set a cancel flag, wait for the running flag to clear, remove the cancel flag, and return. The A* proc can set the running flag, detect cancel flag after each sleep, and if so clear the running flag and return.

Organizing thoughts
How about each unit will have a brain object. The contents of the brain object will be minds. Each mind will have a way of thinking and can gain skill from being exercised.

So when I click an objective, the game tells the unit: "go to this spot instead". The unit uses its brain to see if it needs to cancel a thought. If so, then it tells the mind working on the thought "cancel" and waits for it to acknowledge. Then it chooses the appropriate mind to work on the problem depending on the emotional state. Then it gets the mind working on the problem at a rate depending on the experience and current stress level.

So a unit might have "a mind for safety", or "a mind for efficiency", or "a mind for aggression" and the path from here to there would depend on which "state of mind" they are using to solve the problem. Safety? Include defensive quality of turfs in the heuristics. Efficiency? Just the bare-bones shortest path. Aggression? Include offensive quality of turfs.

Figuring out who should do what
Another problem with the game is trying to decide which unit to scout, defend, attack, etc. There will not be standard classes in the game. However, you will be able to specialize a unit just by limiting how you handle it, so it's skills over time will develop along those lines. This is because they gain experience by practice (with a learning curve).

So let the player name a class, choose a symbol for it, and assign the unit to that class. To help with this, allow them to get a report of units sorted by whatever skill they want. Looking for the sniper? Should you pick the slowest unit or the one with the best aim? Either way, you would be able to choose the skill, sort or reverse sort, and see who comes on top. But still you don't have to play the unit as a sniper just because you assigned him to your "sniper" class. The class name means nothing to game mechanics. Run him around and he'll get more experience at running and not aiming.

Where are my units? Where is my team?
You won't get a team when you start. You'll get newbie "walk-ins" for units. These are people who show up at a paintball field, haven't played much, don't know anybody, etc. You can't buy gear for a walk-in. They bring their own. The nice thing is they cost you nothing. This is good because you don't have any sponsors yet.

Temporary Troops
The game will track how you fare in matches. Play your walk-in's well enough and some might get interested in sticking around for a while. Instead of new people each day, you start retaining units for development. Well, at least for a little while. Now that you have team members, you can start thinking about gear. Buy gear and keep it in your trailer. Temporary units will stay longer if they get to borrow some nicer stuff than what they own.

And now, a word from our sponsor
Teams get noticed, and then the sponsors start to come. Nothing special yet. Maybe it's the local salvage yard owner who will invest a little but you have to let his boy play on your team. Winning matches and gaining sponsors will allow you enough funds to offer your temporary units a contract. Not so temporary anymore! Developing the team makes it attract more sponsors. Spiral up!

Bustin' caps
When retaining units, you start to discover things. Units get only so good at this or that skill then no better. You can't predict this, it just happens. It's the dreaded skill cap. How will you attract new sponsors when you can't develop your team? Eventually the unit reaches its prime and it's not all that prime.

Scouting for units
By now you're stacking some papers, so spend some of it and hire a talent scout. A scouted unit might have better skill caps. It's not guaranteed, but it's possible. Negotiate contracts. Fire people. Now you have a team of units worth the big sponsors and can start serious unit trading with the other players, and participate in the national and international levels.

I guess to muds, this aspect of the game is all about "pets".

Final thought of the day
I don't know how much of this I will implement. For now, I'm going to work on organizing the units so they have brains and minds starting out with this basic A* proc.

Progress report: A*

Tue, 15 Apr 2008 22:37:21 GMT

Worked on the 1st A*. Looking good. Still needs a little more code.

Progress report

Wed, 09 Apr 2008 22:35:18 GMT

The initial priority queue system for Splategy has been debugged and tested successfully. This system was created with recursive methods, so there is extra overhead involved. I'll replace it with an iterative version later when I'm ready to do some optimization.

It was a learning process, where I found out some things about how Byond deletes stuff during assignment, and discovered that the src var has some kind of protection on it.

One thing I'm curious about is whether Byond would del all the nodes without me micromanaging that part. I implemented Del() based on an assumption that it wouldn't, but after seeing how efficiently Byond cleans other parts up without my intervention I think I should check into it.

But as for now, the A* pathfinding algorithm can be implemented. So that's where I will focus development next.

Progress report: Layers and A*

Sat, 05 Apr 2008 23:22:26 GMT

I was able to devote a few hours to Splategy today.

Access between locs currently uses inblock and outblock. To implement this, the following was most useful:

#define uniquedir(X) (1 << X)

so I could do stuff like this:

loc.inblock|=uniquedir(SOUTH)|uniquedir(SOUTHWEST)| uniquedir(WEST)
// ...
Enter(atom/movable/O)
    return !(inblock&uniquedir(O.dir))

Layering of objects is improved. So now objects on each row of the map use layer OBJ_LAYER+2*(world.maxy-y), implemented in the images too as needed.

Moving objects try to get to the right layer while moving (especially diagonal) so that they slide in front of stuff to the north and behind stuff to the south. It works for most cases, but there are some that don't look right yet.

There is a priority queue datum. The code is recursive for now and untested, but the groundwork is there. Currently it allows creating an empty queue, inserting a weighted item, removing/returning the 1st item, and destroying the queue.

Once I verify the functionality of the prioqueue I can turn my attention to implementing the 1st A* proc, which will find the quickest path between loca and locb, avoiding special moves.

I want to make other A* procs which take into consideration heuristics factors like special moves (climbing, swimming, etc), danger, exertion, visibility, etc. These would be available to units who are more experienced. But I won't bother with them until way later in development.

This is a learning experience. Kudos to Patrick Lester (A* Pathfinding for Beginners).

Since some people are curious

Fri, 04 Apr 2008 11:09:55 GMT

The reason I've held back on many details of the game I'm developing is because it is a 'learn as you go' attempt. So everything is subject to change.

So if I mentioned that for now I'm calling it "SPLATegy", and that the theme is paintball, I might lead people into thinking I will actually finish and release such a game. I just don't want to make such a commitment. But so far things have developed to the point where it would be hard to make it go in any other direction than this. So I have to commit to it.

So, since I'm committing, I might as well mention some stuff about it.

The game consists of PvP or PvC matches between 2 teams. A player (or sometimes the computer) runs a team.

A team consists of AI units. AI units have gear and ammo.

This is not a violent game. There are no guns. They are called 'markers'. There is no 'hit points'. If someone 'marks' an enemy unit, it is eliminated from the match.

You win a match by various means:
- elimination
- forfeit
- flag capture
- step on territory
It depends on the type of match.

Gameplay is realtime.
- Click your unit to select it
THEN
- click a turf, the unit is therefore commanded to go to the turf.
- click a wall, the unit is commanded to hit the wall with cover fire, causing nearby enemy to get the urge to duck for cover and perhaps giving you the possibility to move another unit without anyone seeing it happen.
- click an enemy unit, your unit is commanded to find a position within sight of the enemy and fire at it.
- click a friendly unit to select that one instead

Position and facing means probably the most in this game. It determines what is in a unit's line of sight and who can see it. Partial barriers give units advantages. So if you are next to a wall with small holes in it, it is easy to shoot through it, but hard to be shot through it. So there is a "strategic" element.

Your control is not absolute. For example, you might have trouble getting a cowardly unit to advance until you've positioned braver units around to make that area safer. So I guess there is a "puzzle" element to the game. Problem-solving skills will matter.

Your units get better over time at abilities such as aim or dodge. Winning matches gives you a chance to win sponsors and therefore get better gear for your units. You can also trade units with other players. So there is an RPG and market element to the game.

If that makes it seem unbalanced for PvP, you are right, so there will be the option of fighting with developed or preset teams. A match with preset balanced teams then determines the better player. But role playing folks can match developed teams instead to see how they compare.

Speaking of PvP... I hope to offer the ability to take over matches. For example, you want PvP but no one is available. So you can start a PvC match that allows players to take over the opponent. Or let's say you are in a PvP match and "life gets in the way": you have to quit. Instead of ending the game, the computer takes over for you.

I want to include a clan system too. So players join clans, pool resources, etc. And there will be a lounge for chatting and clan rooms for chatting with peers.

Now, with all that said, I haven't implemented all of the above, nor is all of the above all that I have in mind. For example, roles. Consider a unit that is brave and good at dodging, so you assign him/her a medic role for a special type of paintball match. A medic's gear consists of a towel to wipe a mark off of a unit. Another role is sniper. Who knows what role's I'll come up with or even if I'll include these.

Now, for the maps. I enjoy playing at this one paintball park where they have themed areas. For example, "west town" resembles an old west ghost town. There's a forest area, field of hay bales, etc. So this game will be kinda like that. Levels will have motifs. Also there will be some things thrown in just for fun. Music will match the motif of the level.

As for when this game will be ready to present it to the public? Well consider I have 2 jobs and a family of 4 people in a house with 2 computers. So I can't commit to a month or even a year.

But... this is what I'm working on.

Progress report

Tue, 01 Apr 2008 08:22:26 GMT

Last weekend I integrated the orthographic system with the game, created a new tutorial map, and added some outputs to move units around and get a feel for the new look.

This step utterly destroys the ability to walk_towards. I was expecting this, and was thinking about implementation details towards the A*.

Here is the deal:
When a diagonal line of walls is placed across 2 locations, a third location needs to be updated to block entry from across the corner. So instead of density, I need a var access as a union of directions.

Some other progress made: A great sounding VSTi that produces symphonic section sounds by playing a few sonic tricks.

Back from vacation

Mon, 24 Mar 2008 09:02:29 GMT

Progress on game halted due to... VACATION! =)

Now that I'm back, time to get refocused and make progress. I tested out some vst tweaking over the weekend but haven't touched the game in a while. That's about to change.